Change it to whatever you want :) Search and replace is for me much
easyer
then to workaround the inheritance :)
regards,
irukandji
On 2012-04-19 14:56, David Cole wrote:
If that's the case then "NOINHERIT" is not the correct name for this.
(Because that, to me, primarily implies CMake variabl
If that's the case then "NOINHERIT" is not the correct name for this.
(Because that, to me, primarily implies CMake variable value
inheritance, and directory properties, and everything that inherits.)
On Thu, Apr 19, 2012 at 8:48 AM, irukandji wrote:
> What my thought was:
>
> if you are adding
What my thought was:
if you are adding the subdirectory, you want to keep what is stored
within
the cmake variables so you can fine grain what to use and not to use in
subdirectory or pass just some settings from caller, if this would be
also
removed there would be no way to pass anything to
So, wait. This intends to avoid inheritance of preprocessor, compiler
and linker stuff, but it still allows inheritance of all other
directory properties and CMake variable values...?
On Thu, Apr 19, 2012 at 5:04 AM, irukandji wrote:
> Ok, guys, catch... source base is 2.8.7.
>
> add_subdirector
Ok, guys, catch... source base is 2.8.7.
add_subdirectory(source_dir [binary_dir]
[EXCLUDE_FROM_ALL] [NOINHERIT])
/.../
If the NOINHERIT argument is provided, the subdirectory build
configuration
will not inherit any preprocessor, compiler or linker specific
parameters.
I appreciate the idea but my view is that if the solution (whatever
dev. solution)
is not elegant there is something wrong with it.
While testing the posibilities, i had it, i have implemented the
optional dont_inherit
flag to add_subdirectory. Tomorrow (some testing first), I'll submit a
pa
I think I understand what you're trying to do better now. It's a bit
off the beaten path for CMake, and has more moving parts than is
strictly necessary.
It could be set up as a nested suite of ExternalProjects, and avoid
the definitions inheritance issue you're running into.
You could also mana
Hi,
Maybe i can try to reexplain, from head, ignore syntactic errors and
oversimplifying...
**
/sources/cmakelist.txt
/sources/binaries/helloworld
..cmakelists.txt
/sources/binaries/hellocmake
..cmakelists.txt
/sources/libraries
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 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 dep
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 resi
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 wrote:
> Hi,
>
> (as no one answered to my previous email, let me add this: multiplatform
>
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
13 matches
Mail list logo
