[CMake] Determining a library name at configure time
Nils Gladitz
nilsgladitz at gmail.com
Tue Sep 22 17:38:32 EDT 2015
On 22.09.2015 23:17, Bill Newcomb wrote:
> Disclaimer: The system I'm working on has its origins in pre cmake-2.6
> days, and we'd probably make a lot of different decisions if we
> started anew today. We are using only the Unix Makefiles generator.
>
> Our system comprises a number of components, each of which is its own
> cmake project, and builds libraries, executables, etc. The configure
> (and make, later) operations on the components are driven by another
> invocation of cmake (i.e. the user points cmake at a top-level
> cmakelists, which then invokes cmake again for each component; then
> the user runs make, which results in 'make install' getting run in
> each component's configured subdir).
>
> When cmake is run, the user may designate it either as global or
> local--local builds install component products to a local directory in
> the user's workspace, whereas global builds install to a central
> well-known location. Periodic automated builds build all components
> and install globally, so that user builds need not build all
> components, but rather can use some components from the global area
> (with the obvious caveats about version incompatibilities).
>
> I want a way to enable one component to use a static library from
> another component. I tried using cmake's export/import functionality,
> but in that case the exported *.cmake file isn't written until install
> time, but the system must be able to configure all components before
> starting to make them. So I was trying to figure out a way to create
> a skeletal version of the exported *.cmake file at configure time so
> that the dependent component could include an actual dependency on the
> static library to be provided by the other component. Figuring out
> how to get the name of the library is my use case.
>
CMake can also create target exports for the build tree with
export(EXPORT) [1].
These would not require installation and would exist after generation
(after cmake finished processing).
Which might be an option if you can configure your sub-projects in
sequence (e.g. configure the project that provides targets before the
projects that consume those targets).
If cmake's target exports exceed what is required for your use case you
could also use file(GENERATE) to produce custom files at generation time.
file(GENERATE) would take an input file containing e.g. a generator
expression like $<TARGET_FILE_NAME:target> and produce a corresponding
output file with the target's output file name.
Nils
[1] http://cmake.org/cmake/help/v3.3/command/export.html
[2] http://cmake.org/cmake/help/v3.3/command/file.html
More information about the CMake
mailing list