[cmake-developers] cmake --find-package

Alan W. Irwin irwin at beluga.phys.uvic.ca
Wed Apr 23 21:11:17 EDT 2014


On 2014-04-23 17:19-0400 Matthew Woehlke wrote:

> On 2014-04-23 16:21, Alan W. Irwin wrote:
>> [...] I keep making a plea for a proper fix to bug 9220 because
>> propagating compiler information (held potentially in a large number
>> of different environment variables and CMake variables for many
>> different computer languages) from the principal CMake project to the
>> test project is somewhat problematic.
>
> This sounds like it would be relevant to external projects, also. Does this 
> include propagating compile/link flags?
>
> A better and more "canned" solution to the problem of propagating tools and 
> flags in general (e.g. from a superbuild project to its external_project 
> 'children') would be most welcome...
>
> (That said... bonus points for allowing at least compile/link flags to be 
> overridden per sub-project; I have at least one instance where I need this 
> ability, in order to specify strict warning flags "generally" that need to be 
> disabled for a specific sub-project.)

I agree with what you have said.  Of course, a caveat on your first
comment is that if the external projects are built consistently with
ExternalProject_Add and if you have Unix tools or MSYS installed
(including env), then you can use something like

CONFIGURE_COMMAND ${ENV_EXECUTABLE} PATH=${EPA_PATH} "CFLAGS=${CFLAGS}" "CXXFLAGS=${CXXFLAGS}"
${source_PATH}/${EPA_CONFIGURE_COMMAND} @config_arguments@

for, e.g., autotools-based builds to propagate C and C++ flags in a
consistent way.  (This example is taken from my autotools template
file for the epa_build subproject of PLplot.) So for that project I
request epa_build users only specify compile flags via the environment
variables so I can propagate those environment variables to many
different builds as above.  And I do something similar to allow my bug
9220 workaround work as well.

Of course, this approach is problematic because users ignore your
suggestion to limit how they specify compile flags.  So it would be
much better (as you have said) if there was a canned solution to help
propagate whatever method they have used to specify the compile flags
to one consistent method (e.g., by transforming every <lang>-related
method into the the equivalent <lang>FLAGS CMake variable).

Has anyone here implemented such a canned solution? If so, I would
certainly love to test it not only for PLplot's epa_build subproject
but also for the bug 9220 workaround I use for PLplot.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________



More information about the cmake-developers mailing list