[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