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
__________________________
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
