| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Fixes: #18700
|
|
|
|
|
|
|
|
|
| |
The only format supported from the ones available within cpack is
gnutar, which supports large numbers encoded in base-256, and long
filenames and linknames. PAX is not and has never been a supported
format by dpkg.
Fixes: #18620
|
|
|
|
| |
Fixes: #14983, #16561
|
|
|
|
|
| |
Ext and External were used inconsistently in the code and the
docs. This change converts all uses of Ext to External, including
within variable names used by the generator.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Found via `codespell -q 3 -I ../cmake-whitelist.txt --skip="./Utilities"`
where the whitelist consists of
```
aci
ans
behaviour
buil
convertor
dum
earch
ect
emmited
emmitted
helpfull
iff
isnt
ith
lowercased
mose
nd
nknown
nto
objext
ot
pathes
pevents
splitted
substract
superceded
supercedes
te
tim
todays
uint
upto
whitespaces
```
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This generator doesn't actually package the files. Instead, it
provides a metadata JSON file that can be used by external packaging
software to do its own packaging. This JSON file provides information
about the components, component groups, installation types, and CMake
projects.
|
|
|
|
|
|
|
| |
Ensure we use the `cmake` corresponding to the running `cpack`
even if it is not first in `PATH` or has had its name changed.
This was accidentally left out in commit v3.7.0-rc1~81^2 (CPack/RPM:
Generate source rpm (SRPM) packages on demand, 2016-09-19).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These modules are not meant to be included by user code, they are
only an internal implementation detail for CPack. Having them live
in the main Modules directory with documentation was misleading, so
they have been moved into Modules/Internal/CPack, and their
documentation has been stripped following its move into the new
"CPack Generators" section. No-op modules which contained only
documentation have been removed entirely.
The only module that hasn't been moved is CPackIFW, because it
contains user-facing macros which would be lost if it were moved.
So, the CPackIFW module has been updated with a note explaining what
needs to (eventually) happen.
|
|
|
|
|
|
|
| |
Follow up commit e17b179184 (Features: On SunPro link with language
standard compiler flag, 2017-04-28) to apply the same fix to the feature
checks. The `try_compile` used for these is intentionally not using
`CXX_STANDARD`-based logic so that it can test the individual flags.
|
|
|
|
|
|
|
|
|
|
| |
A common use case of `target_compile_features` is simply to specify that
the compiler should be run in a mode that is aware of e.g. C++11. Some
projects simply specify a particular C++11-only feature to request this.
Provide a first-class way to do this by naming features after the
corresponding language standard. Record them as always available in the
corresponding standard level so that requesting them always ensures that
standard (or higher) is used.
|
|
|
|
|
| |
Simplify and de-duplicate per-compiler feature recording macros and
convert to a centralized per-language macro.
|
|
|
|
|
|
|
|
|
|
| |
Since commit v3.1.0-rc1~635^2~7 (project: Add infrastructure for
recording CXX compiler features, 2013-10-17) we compile a test source to
a binary and then extract "<LANG>_FEATURES:..." strings from the binary
with the file(STRINGS) command. Add a newline at the beginning of the
string literal to be sure file(STRINGS) can extract the first entry as a
string independent of whatever else the compiler may put before the
storage it allocates for the literal within the binary.
|
|
|
|
|
|
|
|
|
|
| |
Clang discards the entire string if it is not used, removing
the ability to read the features from the compiled binary. That
is prevented by using the symbol.
GNU with -O3 also discards the string, so use the string in a
way which is determined by a runtime value (argc) to prevent
it being discarded.
|
| |
|
| |
|
|
|
|
|
| |
As a 'built-in' variable it imposes a cost on all variable lookups
and it is expected to be rarely used.
|
|
Add a feature test using the compiler macros and the preprocessor to
determine available features.
Add a CMAKE_CXX_COMPILE_FEATURES variable which contains all features
known to the loaded compiler, and a CMAKE_CXX_KNOWN_FEATURES variable
containing all features known to CMake. Add language standard specific
variables for internal use to determine the standard-specific compile
flags to use.
This will be extended to other languages in the future. Follow-up
commits will add features which will be recorded by the feature test.
|