[CMake] problem with ADD_SUBDIRECTORY always inheriting all settings
Maarten Nieber
hallomaarten at yahoo.com
Tue Feb 1 17:12:36 EST 2011
Hi everybody,
I´m mailing to find out what the community thinks of my feature request
(http://public.kitware.com/Bug/view.php?id=5974), which was unfortunately
rejected, and maybe come up with a better idea that serves the same goal.
However, first I want to say that I appreciate the effort that the CMake team is
putting in this free software. If my feature request really doesn't make it into
CMake, so be it :-)
The plea that I would like to make is that the core functionality of CMake is to
set up the compilation environment, and therefore CMake should avoid
restrictions on which environments you can create. The current problem I see
with ADD_SUBDIRECTORY is that you can create a solution with all your projects,
but it does not give you full control of your environment: child projects will
always inherit all settings from parent projects, including the ones they don't
need or don't want.
A workaround was proposed: let all child projects depend on an empty parent
project. This however will not work, because I'm depending on ADD_SUBDIRECTORY
to create the >real< dependency structure of my project, as this structure will
affect build order and linker dependencies (in fact, I don't think that
ADD_SUBDIRECTORY should create a linker dependency either, but this is a related
but different issue).
My point of view is that CMake should allow you to create exactly the project
dependency structure you require (it already does a good job on this), with the
option to completely control the most common compilation environment variables
(library paths, defines, source paths, etc) of every project. My proposal for
the DONT_INHERIT keyword basically means that you either let CMake do most of
the work (DONT_INHERIT = false), which makes life easy but doesn't give full
control, OR that you put DONT_INHERIT = true and then you have to do more work
yourself (but with complete control). In my opinion, this added flexibility is
worth the possible confusion caused by DONT_INHERIT overruling cached values.
If you have an alternative idea about how to achieve these goals, I'd like to
hear about it.
Thanks for reading,
Maarten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110201/5d3beed8/attachment.htm>
More information about the CMake
mailing list