summaryrefslogtreecommitdiffstats
path: root/Source/cmExportInstallFileGenerator.h
Commit message (Collapse)AuthorAgeFilesLines
* export: Fix handling of import prefixMatthew Woehlke2024-07-261-0/+3
| | | | | | | | | | Fix some additional places in export generation logic that were still hard-coding the import prefix. Change cmGeneratorExpression::Preprocess to take the desired prefix as an argument. (This replaces taking a boolean whether to resolve relative paths; if a non-empty prefix is given, that is used to resolve relative paths, otherwise relative paths are left alone.) This should ensure that import properties always spell the prefix according to the format being generated.
* export: Generalize GenerateImportFileConfigMatthew Woehlke2024-07-251-0/+4
| | | | | | | | | | Move some logic that is specific to CMake-format exports from GenerateImportFileConfig to an overload of GenerateImportConfig, so that the former can be moved (back) to the generic base class. This will allow it to also be used for Common Package Specification exports. To facilitate this, also add a method to get the format-specific character used to separate the export file base name from the config suffix, so that the rest of the logic to determine the file name can be shared.
* export: Refactor obtaining export informationMatthew Woehlke2024-07-251-4/+1
| | | | | | | | Refactor methods in the build and install export file generators to have the same, simplified API. Expose the resulting method as an abstract method on the base class, so that it can be called from mode-agnostic generators. While we're at it, refactor cmExportInstallFileGenerator's version to use std::any_of.
* export: Factor out CMake-specific export generation (2/2)Matthew Woehlke2024-07-231-43/+68
| | | | | | | | | | | | | | | | | | 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.
* export: Fix const placementMatthew Woehlke2024-07-181-5/+5
| | | | | | | | Use clang-format to fix placement of const qualifiers to be consistently right of the typename. The inconsistency was getting annoying, especially as the following refactor changes a lot of methods and sometimes adds const. (Being inconsistent within a file is not ideal, but in some cases there was inconsistency within single lines!)
* export: Factor out CMake-specific export generation (1/2)Matthew Woehlke2024-07-181-0/+5
| | | | | | | | | | | | | | | | 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.
* Merge branch 'backport-cxxmodules-export-file-collisions'Brad King2024-01-181-2/+4
|\
| * cxxmodules: make export trampoline script files uniqueBen Boeckel2024-01-181-2/+4
| | | | | | | | | | | | | | | | | | | | | | Include the name of the `EXPORT` in the filename when generating export information for C++ modules. This allows the same directory to be used for multiple sets of C++ module-using targets. For `export(TARGETS)` uses, generate a name based on the hash of the concatenation of the target names involved with the `export()` call. Fixes: #25609
* | install(EXPORT): Export find_dependency() callsKyle Edwards2023-11-131-1/+7
|/ | | | | | Issue: #20511 Co-Authored-by: Brad King <brad.king@kitware.com> Co-Authored-by: Robert Maynard <rmaynard@nvidia.com>
* cmExport*FileGenerator: support exporting C++ module propertiesBen Boeckel2022-07-061-0/+25
| | | | | C++ module properties will be generated at build time, so generate code that includes the files actually responsible for the information.
* cmExportFileGenerator: Simplify collection of targets missing from export setBrad King2022-04-111-6/+3
| | | | | Store the list of missing target names in a member instead of threading an explicit reference to it through the call stack.
* install(EXPORT): Install file setsKyle Edwards2021-10-271-0/+6
|
* Refactor export file generator intefaceEugene Shalygin2021-07-221-4/+4
| | | | | Replace cmTargetExport with const cmGeneratorTarget to allow recursive processing of exported targets and their link dependencies.
* Modernize: Use #pragma once in all header filesKitware Robot2020-09-031-4/+1
| | | | | | | | | | | | | | | | #pragma once is a widely supported compiler pragma, even though it is not part of the C++ standard. Many of the issues keeping #pragma once from being standardized (distributed filesystems, build farms, hard links, etc.) do not apply to CMake - it is easy to build CMake on a single machine. CMake also does not install any header files which can be consumed by other projects (though cmCPluginAPI.h has been deliberately omitted from this conversion in case anyone is still using it.) Finally, #pragma once has been required to build CMake since at least August 2017 (7f29bbe6 enabled server mode unconditionally, which had been using #pragma once since September 2016 (b13d3e0d)). The fact that we now require C++11 filters out old compilers, and it is unlikely that there is a compiler which supports C++11 but does not support #pragma once.
* Revise include order using clang-format-6.0Kitware Robot2019-10-011-3/+3
| | | | | Run the `clang-format.bash` script to update our C and C++ code to a new include order `.clang-format`. Use `clang-format` version 6.0.
* cmExportInstallFileGenerator: improve error messageBen Boeckel2019-08-201-3/+4
| | | | | | | Following commit 49cfd390 (cmExportBuildFileGenerator: improve error message, 2019-06-26), improve the error message related to installed export sets by referencing the files which contain the exported target ambiguously.
* Fix misc. typosluz.paz2018-06-041-1/+1
| | | | Found via `codespell` and `grep`
* install,export: Maybe transform OBJECT libraries to INTERFACE librariesBrad King2018-02-281-0/+4
| | | | | | | | | | | Teach the `install` and `export` commands to support installing and exporting `OBJECT` libraries without their object files. Transform them to `INTERFACE` libraries in such cases. For `install(TARGETS)`, activate this when no destination for the object files is specified. For `export`, activate this only under Xcode with multiple architectures when we have no well-defined object file locations to give to clients.
* Use C++11 override instead of CM_OVERRIDEBrad King2017-09-151-5/+5
| | | | | | | | We now require C++11 support including `override`. Drop use of the old compatibility macro. Convert references as follows: git grep -l CM_OVERRIDE -- '*.h' '*.hxx' '*.cxx' | xargs sed -i 's/CM_OVERRIDE/override/g'
* IWYU: Mark cmConfigure.h with pragma: keepDaniel Pfeifer2017-08-261-1/+1
| | | | Also remove `#include "cmConfigure.h"` from most source files.
* Use quotes for non-system includesDaniel Pfeifer2017-04-111-1/+1
| | | | | | | | | | | | | Automate with: git grep -l '#include <cm_' -- Source \ | xargs sed -i 's/#include <\(cm_.*\)>/#include "\1"/g' git grep -l '#include <cmsys/' -- Source \ | xargs sed -i 's/#include <\(cmsys\/.*\)>/#include "\1"/g' git grep -l '#include <cm[A-Z]' -- Source \ | xargs sed -i 's/#include <\(cm[A-Z].*\)>/#include "\1"/g'
* Simplify CMake per-source license noticesBrad King2016-09-271-11/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Per-source copyright/license notice headers that spell out copyright holder names and years are hard to maintain and often out-of-date or plain wrong. Precise contributor information is already maintained automatically by the version control tool. Ultimately it is the receiver of a file who is responsible for determining its licensing status, and per-source notices are merely a convenience. Therefore it is simpler and more accurate for each source to have a generic notice of the license name and references to more detailed information on copyright holders and full license terms. Our `Copyright.txt` file now contains a list of Contributors whose names appeared source-level copyright notices. It also references version control history for more precise information. Therefore we no longer need to spell out the list of Contributors in each source file notice. Replace CMake per-source copyright/license notice headers with a short description of the license and links to `Copyright.txt` and online information available from "https://cmake.org/licensing". The online URL also handles cases of modules being copied out of our source into other projects, so we can drop our notices about replacing links with full license text. Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority of the replacements mechanically. Manually fix up shebang lines and trailing newlines in a few files. Manually update the notices in a few files that the script does not handle.
* Export: Virtualize file generation step helpersBill Hoffman2016-09-081-5/+5
| | | | Allow subclasses to override the actual content generation.
* Export: Factor out file generation steps into helpersBill Hoffman2016-09-081-0/+8
| | | | | Do not actually generate any content in the driving code paths. Use helpers for that.
* fix a load of include-what-you-use violationsDaniel Pfeifer2016-09-031-0/+10
|
* mark functions with CM_OVERRIDEDaniel Pfeifer2016-06-271-9/+9
|
* Revise C++ coding style using clang-formatKitware Robot2016-05-161-12/+11
| | | | | | | | | | | | | Run the `Utilities/Scripts/clang-format.bash` script to update all our C++ code to a new style defined by `.clang-format`. Use `clang-format` version 3.8. * If you reached this commit for a line in `git blame`, re-run the blame operation starting at the parent of this commit to see older history for the content. * See the parent commit for instructions to rebase a change across this style transition commit.
* Export: Port internal utility to cmGeneratorTarget.Stephen Kelly2015-10-181-4/+4
|
* Export: Port some API to cmGlobalGenerator.Stephen Kelly2015-10-181-2/+1
|
* cmGeneratorTarget: Move GetInstallNameDir* from cmTarget.Stephen Kelly2015-08-051-1/+2
|
* install: Allow absolute EXPORT destination with relative targets (#15258)Brad King2014-12-151-4/+0
| | | | | | | | | | | | | | | | | When install(EXPORT) is given an absolute destination we cannot compute the install prefix relative to the installed export file location. Previously we disallowed installation of targets in such exports with a relative destination, but did not enforce this for target property values besides the location of the main target file. This could lead to broken installations when the EXPORT is installed to an absolute path but usage requirements are specified relative to the install prefix. Since an EXPORT installed to an absolute destination cannot be relocated we can just hard-code the value of CMAKE_INSTALL_PREFIX as the base for relative paths. This will allow absolute install(EXPORT) destinations to work with relative destinations for targets and usage requirements. Extend the ExportImport test with a case covering this behavior.
* stringapi: Pass configuration names as stringsBen Boeckel2014-03-081-3/+3
|
* strings: Remove cmStdString referencesBen Boeckel2014-03-081-2/+2
| | | | | | | | | | | Casts from std::string -> cmStdString were high on the list of things taking up time. Avoid such implicit casts across function calls by just using std::string everywhere. The comment that the symbol name is too long is no longer relevant since modern debuggers alias the templates anyways and the size is a non-issue since the underlying methods are generated since it's inherited.
* OS X: Add support for @rpath in export files.Clinton Stimpson2013-06-031-0/+2
| | | | | Also expand the IMPORTED_SONAME property for targets to match the install_name.
* Remove unused forward declarations.Stephen Kelly2013-02-091-3/+0
|
* Add the INSTALL_PREFIX genex.Stephen Kelly2013-01-271-0/+2
|
* Move the exported check for dependencies of targetsStephen Kelly2013-01-151-2/+4
| | | | | Check only once, in the Config.cmake file, instead of once in each Config-<cfg>.cmake file.
* exports: move the handling of missing targets into subclassesAlex Neundorf2012-09-301-3/+13
| | | | | | | | | | Before, cmExportFileGenerator::ComplainAboutMissingTarget() was a virtual function which had to be implemented in the subclasses. It is not anymore. Instead, there is now a virtual function HandleMissingTargets(), which is implemented in the two subclasses. This makes e.g. dealing correctly with APPEND mode easier. Alex
* exports: accept a missing target if it is exported exactly onceAlex Neundorf2012-09-281-1/+2
| | | | | | | | | | | If a target is exported, and a library it depends on is not part of the same export set, before this patch cmake errored out. With this patch, it now checks whether the missing target is exported somewhere else exactly once, and accepts in this case (because then it can determine the namespace for the missing target and use this). Alex
* exports: Hold an ExportSet pointer in cm*Export*GeneratorYury G. Kudryashov2012-09-281-12/+1
| | | | Get name from this->ExportSet.
* exports: Create class cmExportSetYury G. Kudryashov2012-09-281-2/+3
| | | | | Replace direct use of 'std::vector<cmTargetExport const*>' with a dedicated class.
* exports: Move cmTargetExport to a dedicated header fileYury G. Kudryashov2012-09-281-30/+0
|
* install(EXPORT): Enforce existence of imported target filesAlex Neundorf2011-11-221-1/+3
| | | | | | | | | | Typical <package>Config.cmake files for find_package() rely only on the files generated by install(EXPORT). They might be wrong, for whatever reasons, like people manually deleted files, projects were packaged wrong by distributions, whatever. To protect against this, add checks that the file locations we are importing actually exist on disk. Alex
* Convert CMake to OSI-approved BSD LicenseBrad King2009-09-281-14/+9
| | | | | | | This converts the CMake license to a pure 3-clause OSI-approved BSD License. We drop the previous license clause requiring modified versions to be plainly marked. We also update the CMake copyright to cover the full development time range.
* ENH: Refactor computation of import file globBrad King2009-01-071-0/+4
| | | | | | New method cmExportInstallFileGenerator::GetConfigImportFileGlob computes the globbing expression that an installed export file uses to load its per-configuration support files.
* ENH: Pass dependent library search path to linker on some platforms.Brad King2008-02-011-1/+2
| | | | | | | | | | | | | | | | - Move runtime path ordering out of cmComputeLinkInformation into its own class cmOrderRuntimeDirectories. - Create an instance of cmOrderRuntimeDirectories for runtime path ordering and another instance for dependent library path ordering. - Replace CMAKE_DEPENDENT_SHARED_LIBRARY_MODE with explicit CMAKE_LINK_DEPENDENT_LIBRARY_FILES boolean. - Create CMAKE_LINK_DEPENDENT_LIBRARY_DIRS boolean. - Create variables to specify -rpath-link flags: CMAKE_SHARED_LIBRARY_RPATH_LINK_<LANG>_FLAG CMAKE_EXECUTABLE_RPATH_LINK_<LANG>_FLAG - Enable -rpath-link flag on Linux and QNX. - Documentation and error message updates
* ENH: Updated exporting and importing of targets to support libraries and ↵Brad King2008-01-281-0/+122
configurations. - Created cmExportFileGenerator hierarchy to implement export file generation - Installed exports use per-config import files loaded by a central one. - Include soname of shared libraries in import information - Renamed PREFIX to NAMESPACE in INSTALL(EXPORT) and EXPORT() commands - Move addition of CMAKE_INSTALL_PREFIX to destinations to install generators - Import files compute the installation prefix relative to their location when loaded - Add mapping of importer configurations to importee configurations - Rename IMPORT targets to IMPORTED targets to distinguish from windows import libraries - Scope IMPORTED targets within directories to isolate them - Place all properties created by import files in the IMPORTED namespace - Document INSTALL(EXPORT) and EXPORT() commands. - Document IMPORTED signature of add_executable and add_library - Enable finding of imported targets in cmComputeLinkDepends
generated by cgit v0.12 at 2025-09-13 09:55:06 (GMT)