[CMake] Add configuration support to include_directories()

[Robert Dailey]

Why I need this feature is irrelevant, the important thing is that I need
the feature. I know a couple of other people who've posted on various other
mailing lists that have asked for this as well.

However, if you must know, I need this mainly because of wxWidgets.
wxWidgets has a setup.h file that is located in a directory specific to the
configuration in which wxWidgets was built. For the respective
configuration, I need to tell the compiler to use a different setup.h, which
means I need to specify a different include directory per configuration.
There's other ways to solve this problem other than using include
directories, but this is the most trivial and simplified way.

On Tue, Dec 23, 2008 at 5:00 AM, cyril_wobow <cyril at wobow.com> wrote:

> Philip Lowman a écrit :
>
>> On Mon, Dec 22, 2008 at 11:27 PM, Robert Dailey <rcdailey at gmail.com<mailto:
>> rcdailey at gmail.com>> wrote:
>>
>>    On Mon, Dec 22, 2008 at 9:23 PM, Bill Hoffman
>>    <bill.hoffman at kitware.com <mailto:bill.hoffman at kitware.com>> wrote:
>>
>>
>>               Investigate CMAKE_CFG_INTDIR.
>>
>>
>>            I believe for Visual Studio output, this will be
>>            $(OutDir), right? If this is the case, this is a visual
>>            studio environment variable that will have no meaning when
>>            used in CMake scripts.
>>
>>
>>        It is . when not in VS, and $(OutDir) when it is.  So, you can
>>        say /foo/bar/bin/${CMAKE_CFG_INTDIR}/runit.
>>
>>        It will be /foo/bar/bin/./runit with makefiles.
>>        It will be /foo/bar/bin/$(OutDir)/runit with VS projects.
>>
>>
>>    Keep in mind this is for include directories, which will not work
>>    with visual studio environment variables. I need to statically
>>    tell CMake which include directories go along with what
>>    configuration. I don't believe this can be done at the moment, at
>>    least with visual studio generation.
>>
>>
>> Just curious, why would you ever want to have two different include
>> directories, one for debug and one for release?  It doesn't seem like a very
>> good idea to me, but then again perhaps there is a good use case for this.
>>  How many header files are affected?  I assume you are aware of and have
>> rejected using the NDEBUG definition for your problem (via a 3rd wrapper
>> file for every affected header file)
>>
>> --
>> Philip Lowman
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> CMake mailing list
>> CMake at cmake.org
>> http://www.cmake.org/mailman/listinfo/cmake
>>
>
> Hi
>
> That sounds funny. Each time I see a question about "how to do something
> configuration-specifically when generating for visual studio" it ends up
> "why on earth would you want to do that?". I guess it proves one more time
> that visual studio users expect every feature that cmake provides at
> configuration-time to also be provided at pre-build time. Thanks to a lot of
> cmake scripting, I have managed to get something like that to work but it is
> true that some features are still not utilizable configuration-specifically.
> (Last critical thing for me was how to tell cmake which CMAKE_BUILD_TYPE is
> "debug" and which is "optimized", which is why I am bound to use cmake from
> cvs where Brad King introduced a DEBUG_CONFIGURATIONS global property).
> I am really interested ni cmake developers' feelings about that.
>
> Cyril
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20081223/f8625017/attachment.htm>