I don't know how you'd ever maintain a sane overall project if it
depends on each subdirectory having conflicting compiler flags.
Well here is the fun, there is not something like "you", we are taling
about
over 100 developers and if everyone is handling his own garden, this is
not
a problem. I cant tell you the details (the lawyers stuff) but believe
me it
is as sane as it can be in regards of doing insane things :)
I'll check your suggestions tomorrow, thank you.
Regards,
irukandji
On 2012-04-17 20:54, Kent Williams wrote:
I think then that you shouldn't use add_subdirectory.
I'd suggest using the ExternalProject module in this case, because it
uncouples the subdirectory's project from the parent project. In
that
case, each subdirectory can be its own project and maintain private
configurations.
You can manage dependencies between ExternalProjects with the DEPENDS
keyword.
I think that what you're describing doesn't really make any sense to
me. I don't know how you'd ever maintain a sane overall project if
it
depends on each subdirectory having conflicting compiler flags.
Another way you can manage this sort of thing is to use Source file
properties -- see SET_SOURCE_FILE_PROPERTIES in the CMake
documentation and the "Properties on Source Files" section as well.
On Tue, Apr 17, 2012 at 1:27 PM, irukandji <irukan...@voidptr.eu>
wrote:
Oh, hi :)
Well, the add_subdirectory takes all the preprocessor defines and
include/library
paths defined before calling it into the added "subdirectory"
cmakelists.txt.
If cmakelists.txt A defines -DWhatever and calls
add_subdirectory(/B) where
the
cmakelists.txt for building library B resides then the library B is
going to
be
built with -DWhatever. This is probably great behaviour for some
cases but
can
also be undesired:
in my case, each library has its own description file, residing in
same
directory
as its cmakelists.txt, with only one function, which is included and
called
with few
parameters to specify runtime etc. by each binary which has a
dependancy to
library.
The description file function sets the -I to itself for caller, the
-l to
its output
and, if the output file is not found, also calls add_subdirectory on
its own
directory.
This is a perfect situation for developers as we can just do out of
source
configuration
for whatever directory (where project resides) and only the
dependancy tree
for that
particular binary is built.
It also brings additional benefit that the team which takes care
about
specific
library also takes care for description file and needed defines
which splits
the
ownership of projects and also presents a single point of inclusion
for that
particular
library, meaning only one file has to be changed for library
specializations.
For the nightly builds, only executables are added to the build
while
everything
else is built only if actually used.
It works great, but the add_subdirectory is propagating the settings
from
executable
to dependant libraries and messes the build.
The question actually is: can i workaround this behaviour and if
not, can
you please
include the parameter to add_subdirectory function to NOT propagate
the
settings.
Regards,
Irukandji
On 2012-04-17 17:58, Kent Williams wrote:
Frankly, I don't entirely understand what the problem is, or what
your
proposed solution is.
What is it that you don't want the subdirectory context to inherit?
On Tue, Apr 17, 2012 at 10:30 AM, irukandji <irukan...@voidptr.eu>
wrote:
Hi,
(as no one answered to my previous email, let me add this:
multiplatform
project with few million lines
of code, sheer size of the project is not allowing to turn around
whole
directory tree as price / performance
is a very relevant factor and even rewriting makefiles/vcprojs to
cmake
will
take months)
The add_subdirectory inheritance striked which is practically a
show
stopper, it was already discussed here
http://www.mail-archive.com/cmake@cmake.org/msg34291.html What was
proposed
(DONT_INHERIT) was a great idea
and improvement to versability of CMake and also harmless for
backward
compatibility so i dont really
understand why forcing subproject to inherit all the settings.
Yes, what is added with add_subdirectory is not a child but a
sibling or
even some other part of the tree
but the point is that it doesnt stop the cmake from building it
correctly
but this inheritance is a problem
as it adds include directories to wrong versions of headers in
public
libs
(due to bugs in different versions,
affecting different platforms,... the unification is impossible),
the
flags
are used on wrong places etc.
Is there a way to workaround it?
Thank you.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
