`mkdtemp` is not available on this architecture until SunOS 5.11.
Look up the symbol at runtime, and if missing, fall back to an
approximate implementation.
Add a helper class to read CPS files. Use this to teach find_package how
to consider and accept .cps files in its search. (Note that no version
testing is performed at this time.) Add a simple test that we can find a
package from a .cps file and correctly extract the version information.
Note that this doesn't actually import anything from CPS yet.
Create a `cm::PathResolver` helper to compute normalized paths.
Provide a common implementation with compile-time dispatch to
select details w.r.t. symbolic links, existence, and matching
the on-disk case of existing paths. Later we can use this to
implement:
* `ToNormalizedPathOnDisk`: Normalizes paths while resolving symlinks
only when followed by `..` components. Does not require paths to
exist, but reads on-disk case of paths that do exist (on Windows).
* `GetRealPath`: Normalizes paths while resolving all symlinks.
Requires paths to exist, and reads their on-disk case (on Windows).
* `CollapseFullPath`: Normalizes paths in memory without disk access.
Assumes components followed by `..` components are not symlinks.
Abstract filesystem access through runtime dispatch so that we can test
Windows symbolic link and network path behavior without relying on real
environments. The overhead of runtime dispatch should be insignificant
during real filesystem access.
Issue: #16228
Issue: #17206
Add initial support for exporting (install only, for now) Common Package
Specification (https://cps-org.github.io/cps/) format package
descriptions. This has some limitations, such as not supporting
generator expressions (as these cannot be portably exported), and only
partially supporting transitive dependencies, but should be usable for
at least some simple cases. (Actually, $<LINK_ONLY> is theoretically
supportable, but is not yet implemented.)
This still needs tests; these will be added in the next commit. Other
potential improvements include support for language-specific compile
definitions and inferring some package properties from project
properties. Additionally, there is no module support yet; this is partly
pending on having a tool agnostic format for providing the necessary
information.
* Wraps the llpkgc parser with cmPkgConfigParser
* Adds various resolution and mangling code under cmPkgConfigResolver
* Documents new command cmake_pkg_config(EXTRACT). Documentation is written with
the assumption additional subcommands will be added soon.
* Adds various tests for the above
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.
It is only needed for libuv < 1.19, but since commit c050d6a01e
(string(TIMESTAMP): add %f specifier for microseconds, 2022-01-27,
v3.23.0-rc1~59^2) we require libuv >= 1.28.
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