| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ff24058e46 export: Use std::all_of to collect exports
20fa4ce8d8 export: Factor out CMake-specific export generation (2/2)
6c66340a64 export: Fix const placement
1bceab3520 export: Factor out CMake-specific export generation (*/2)
a6cc595772 export: Factor out CMake-specific export generation (1/2)
0352376e44 export: Immediately report actual version required
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !9646
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In order to support generation of Common Package Specifications, the
mechanisms CMake uses to export package information need to be made more
abstract. The prior commits began this refactoring; this continues by
(actually) restructuring the classes used to generate the actual export files.
To minimize churn, this introduces virtual base classes and
diamond inheritance in order to separate logic which is format-agnostic
but depends on the export mode (build-tree versus install-tree) from
logic which is format-specific but mode-agnostic.
This could probably be refactored further to use helper classes instead,
and a future commit may do that, however an initial attempt to do that
was proving even more invasive, such that this approach was deemed more
manageable.
While we're at it, add 'const' in more places where possible.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In order to support generation of Common Package Specifications, the
mechanisms CMake uses to export package information need to be made more
abstract. As a first step toward this, refactor cmInstallExportGenerator
so that logic specific to config.cmake and Android .mk lives in separate
subclasses.
While we're at it, clean up the code style a bit and try to use moves a
bit more consistently.
This is step 1 of 2. The next step will refactor the individual file
generators along similar lines, which will also involve creating
additional classes for format-agnostic logic that is shared between
build-tree and install-tree variants.
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
35eb28bc76 bootstrap: Restore support for system jsoncpp and uv without pkg-config
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Alex Turbov <i.zaufi@gmail.com>
Merge-request: !9679
|
| |
| |
| |
| |
| |
| |
| | |
In commit da5de7f9f3 (bootstrap: Allow --boostrap-system-* libraries
custom prefixes, 2024-03-03, v3.30.0-rc1~456^2) the non-pkg-config code
path for uv/jsoncpp/rhash all set `use_librhash_ldflags` instead of
their own variable.
|
|/ |
|
|
|
|
|
|
| |
Provide a way to parse the architectures of a Mach-O binary.
Issue: #25952
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our vendored curl only enables the Secure Transport backend by default
(`CURL_SSL_BACKEND=secure-transport`), but it is limited to TLS 1.2.
The macOS SDK provides the curl development components, and the
corresponding `libcurl.4.dylib` runtime library comes with macOS.
On macOS 12 and above, the default `CURL_SSL_BACKEND=openssl`
backend seems to be capable of selecting TLS 1.3 at runtime for
https connections.
Unfortunately the macOS version of curl, even on macOS 14.4, does
not accept `CURL_SSLVERSION_TLSv1_3` at runtime to enforce TLS 1.3.
However, while our vendored curl accepts the option and passes it
to Secure Transport, macOS does not actually enforce it anyway.
Fixes: #25870
Fixes: #23701
|
|
|
|
|
|
| |
If pkg-config is available, we can query it for the correct -l/-L flags.
This fixes the --boostrap-libuv build for me with libuv installed into
$HOME and PKG_CONFIG_PATH set appropriately
|
| |
|
|
|
|
|
|
| |
Issue: #20511
Co-Authored-by: Brad King <brad.king@kitware.com>
Co-Authored-by: Robert Maynard <rmaynard@nvidia.com>
|
|
|
|
|
|
| |
como: Comeau-not updated since 2008, unlikely to work with CMake
icc: discontinued for icx
icc: not for C++, put in 20 years ago, probably never used / worked
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
48ee946fdc cmExperimental: recycle the C++ modules API UUID
1a1806a71b gitlab-ci: declare `bmionly` support for modules where possible
457a12f3f9 Tests/RunCMake/CXXModules: add tests which use modules from imported targets
9b9ec70b54 Ninja: generate scanning and build rules for C++20 module synthetic targets
80ef50a191 CXXModules: add a variable for BMI-only compilation
80d6544398 cxxmodules: generate synthetic targets as an initial pass
3dc6676ecc cmSyntheticTargetCache: add a struct for synthetic target caching
cb356b540c cmCxxModuleUsageEffects: add a class to capture module usage effects
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !8535
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When importing a C++ module, there may be requirements imposed by the
importer so that the compiler can reliably read the BMI. For example,
the standard used in the importer may need to also apply to the imported
BMI.
Right now, there are no tracked requirements. As we learn more, this
class can start tracking more information.
See: https://wg21.link/p2581r2
|
| | |
|
| |
| |
| |
| |
| | |
Using `_XOPEN_SOURCE=600` on Solaris 5.10, as we do on Solaris 5.11+
already, allows the system headers to be included in C99 and C11 modes.
|
|/ |
|
|
|
|
| |
Issue: #21752
|
| |
|
|
|
|
|
|
| |
This was accidentally left out of commit 5ec69eb58c (cppdap: Build as
part of CMake or use external installation, 2023-05-19,
v3.27.0-rc1~45^2~1).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Depends on cppdap and jsoncpp.
- Add --debugger argument to enable the Debugger.
- Add --debugger-pipe argument for DAP traffics over named pipes.
- Support breakpoints by filenames and line numbers.
- Support exception breakpoints.
- Call stack shows filenames and line numbers.
- Show Cache Variables.
- Show the state of currently defined targets,
tests and directories with their properties.
- Add cmakeVersion to DAP initialize response.
- Include unit tests.
Co-authored-by: Ben McMorran <bemcmorr@microsoft.com>
|
|
|
|
|
|
| |
Rather than treating the user-provided CXX as a space-separated series of
compilers, treat it as a single command-line fragment which possibly
contains flags.
|
|
|
|
|
|
| |
Rather than treating the user-provided CC as a space-separated series of
compilers, treat it as a single command-line fragment which possibly
contains flags.
|
|
|
|
| |
They may contain flags.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
c5c3aff1f5 Autogen: Add INTERFACE_AUTOMOC_MACRO_NAMES target property
69cf9700e6 Autogen: Defer setup until Generate step
7cecb6353e cmGeneratorTarget: Factor out EvaluatedTargetProperty infrastructure
2daba01ddf cmGeneratorTarget: Avoid incidental include-what-you-use warning
850b4d990c IWYU: Add mapping for 'std::remove_reference<Defer &>::type'
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8391
|
| |
| |
| |
| |
| | |
Make it available outside the `cmGeneratorTarget` implementation.
In particular, we will later use it in `cmQtAutoGenInitializer`.
|
|/
|
|
| |
Fixes: #24548
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
23de1675fd libuv: Update CMake-internal buildsystem for 1.44.2
ff82df301c Merge branch 'upstream-libuv' into update-libuv
a23da15596 libuv 2022-07-12 (0c1fa696)
cfe8fd6421 libuv: Update script to get libuv 1.44.2
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7709
|
| | |
|
| |
| |
| |
| | |
Make the command available to CMake's own CMake code.
|
| |
| |
| |
| |
| |
| |
| | |
Add block() and endblock() commands offering the capability to create
new scopes for variables and/or policies.
Fixes: #20171
|
| | |
|
| |
| |
| |
| |
| | |
This will allow all generators to share an implementation for actually
writing out the module map formats.
|
|/ |
|
| |
|
|
|
|
| |
Fixes: #22775
|
| |
|
|
|
|
|
|
|
| |
Since commit 5c58a7e4d2 (ppc64: Work around TOC overflow with platform
specific linker flags, 2019-02-27, v3.15.0-rc1~460^2) we use a bigtoc
flag on this platform when building CMake with CMake. Add it to the
bootstrap script too.
|
| |
|