# [footer]
# //////////////////////////////////////////////////////////////////////////////
# [title.type]
# Must be one of the following:
# - fix: Commits that fix bugs
# - feat: Commits that add new features
# - refactor: Commits that change existing code without changing any behavior
# - perf: Special refactor commits that improve performance
# - style: Commits that do not affect meaning (white-space, formatting, etc.)
# - test: Commits that add tests or fixing existing tests
# - docs: Commits that affect documentation only
# - build: Commits that change build components (scripts, CI pipeline, etc.)
# - chore: Miscellaneous commits (modifying .gitignore, etc.)
# - tag: Commits for adding tags
#
# [title.scope]
# The scope should be the name of the npm package affected. The following is
# the list of supported scopes:
# - xa: XAgent (default)
# - usi: Unified Storage Interface
# - uls: Unified Log System
#
# [title.summary]
# Use the summary field to provide a succinct description of the change:
# - Use the imperative, present tense: "change" not "changed" nor "changes"
# - Don't capitalize the first letter
# - No period (.) at the end
#
# [body]
# Just as in the summary, use the imperative, present tense: "fix" not "fixed"
# nor "fixes".
#
# Explain the motivation for the change in the commit message body. This commit
# message should explain why you are making the change. You can include a
# comparison of the previous behavior with the new behavior in order to
# illustrate the impact of the change.
#
# [footer]
# The footer can contain information about breaking changes and deprecations
# and is also the place to reference GitHub issues, JIRA tickets, and other PRs
# that this commit closes or is related to. For example:
#
# Resolves XCAGENT-100
# Resolves XCAGENT-100, SEAL-1500, XCAGENT-512
#
# BREAKING CHANGE: <breaking change summary>
# <BLANK LINE>
# <breaking change description + migration instructions>
# <BLANK LINE>
# <BLANK LINE>
# Resolves <JIRA ticket>
#
# DEPRECATED: <what is deprecated>
# <BLANK LINE>
# <deprecation description + recommended update path>
# <BLANK LINE>
# <BLANK LINE>
# Resolves #<JIRA ticket>
The original minimum CMake version 3.0 will cause the following CMake
warning:
CMake Deprecation Warning at CMakeLists.txt:31 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version
of CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to
tell CMake that the project does not need compatibility with older
versions.
In order to fix this warning, we need to increase the minimum CMake
version to 3.5.
Specifing the path twice would cause CMake to think that the include
files were being installed to "{PREFIX}/DESTINATION", which would cause
package inclusion to fail.
This way the exported header file can be used cleanly
by searching the exported config package, more so
when nonstandard paths are used for installing header.
Also use expression template to differentiate between
potentially different paths during time of compilation
and module use.
Resembles doc "cmake/help/latest/guide/importing-exporting".
Currently several argtable3 options can be modified only by changing
them in source code. This commit makes these options configurable by
adding ifndef guards: ARG_DSTR_SIZE, ARG_CMD_NAME_LEN,
ARG_CMD_DESCRIPTION_LEN.
ARG_DSTR_SIZE option is moved to argtable_private.h for two reasons:
- Having them in argtable_private.h allows defining compiler flags
(such as -DARG_DSTR_SIZE=100) for argtable3 files only. If the
definitions are in the public header file (argtable3.h) then
technically we have to pass -DARG_DSTR_SIZE=100 also to other files
in the project, so that they evaluate argtable3.h in the same way.
- Having them in argtable3.h is actually not necessary, since they
are not used anywhere in the public interface.
For the same two reasons, ARG_REPLACE_GETOPT has also been moved into
argtable3_private.h in the same commit.
Currently to configure ARG_ENABLE_TRACE or ARG_ENABLE_LOG, we have to
modify argtable3 source code. This commit allows setting these options
via the compiler flags.
1. If newline found in text, it is printed and column count is reset.
Previously line wrap would not take newlines found in text into account.
Resulting in line wrap feature working incorrectly.
Example:
text: "a b\n c d"
line width: 6
previously:
"a b"
"c" <- c in new line because of \n in text
"d" <- d in new line because column count reached 6 at "c"
and line wrap inserted newline
now:
"a b"
"c d" <- "c d" in new line because of \n in text,
line wrap does not insert newline between c and d
2. If a very long word is in text, it is broken up differently than before.
Previously the long word was printed one character per line.
Now as much characters of the long word as can fit in a line are printed.
Example:
text: "test"
line width: 3
previously:
t
e
s
t
now:
tes
t
In GCC, we use __attribute__((optimize(0))) to turn off compiler
optimization. However, in Clang we should use optnone instead of
optimize(0).
closes: #68
Currently CMake scripts will generate both dynamic and static libraries
at the same time. However, CMake recommends using BUILD_SHARED_LIBS to
build either dynamic or static library, which is enforced by vcpkg.
Use BUILD_SHARED_LIBS to build one library type at a time, so that
developers can use vcpkg manifest mechanism to install Argtable3.
We also add namespace (argtable3::) to the package and generate CMake
config version file (Argtable3ConfigVersion.cmake), which can be used to determine the library version in find_package().
The CMake scripts depend on the version.tag file in the project root to
determine the library version. However, current release archives do not
have this file.
Add version.tag to release archives, so developers and vcpkg can use the
file to generate correct Argtable3ConfigVersion.cmake and DLL version
resource.
In MinGW64/MinGW32 environment, gcc will give warnings when we use 'char'
as an array subscript, and when we use C11 functions, such as getenv_s().
We use explicit casting to resolve the array subscript issues, and check
if the build environment supports C11 before calling C11 functions.
resolves#61
Tom Huang
Wouter Wijsman
Terence Noone
Sergey Fedorov
Trevor Flynn
Schdro
PengZheng
Ivan Grokhotkov
Chip Weinberger
peter.hrovat
Andrew Aladjev
YAMAMOTO Takashi