.
Regards,
irukandji
On 2012-04-18 21:07, irukandji wrote:
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
this should work, there
is
always a possibility i have missed something i am not aware of)
Regards,
irukandji
On 2012-04-19 12:10, David Cole wrote:
So, wait. This intends to avoid inheritance of preprocessor, compiler
and linker stuff, but it still allows inheritance of all other
directory properties
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 variable
a
patch, i hope it
will be accepted as it is completely unintrusive, backward compatible,
insert the casual
buzzwords,...
Regards,
irukandji
On 2012-04-18 18:18, Kent Williams wrote:
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
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
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
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
will inherit the include path from gfx library which
you really
dont want. It will also inherit -DUSING_GFX even if it has nothing to
do with it.
Regards,
irukandji
On 2012-04-17 22:56, irukandji wrote:
I don't know how you'd ever maintain a sane overall project if it
depends on each
a LAST, LST resort as the differences
between the different libProblematic configurations are minimal and
making mutiple files out of it will diverge to out of
sync condition...
Thank you for at least reading it, everything else is eternal gratitude
:)
Irukandji
p.s.: btw i would prefer
