[CMake] debug/optimized include directories

[Robert Dailey]

I'd like to get an overall update on the plans for this from the kitware
guys, as well as propose an extension to this feature.

Honestly I think the exact facilities we have now for libs we should have
for source directories. This includes:
- debug/release configurations for include directories
- New target properties for include directories
- Transitive behavior for include directories
- private/public specification for include directories

Point #3 is what I think is important, because right now I have a lot of
complex dependency recursion logic in my CMake scripts JUST to make sure
include directories for dependencies are added to targets that include
those dependencies.

For Point #4, I think this is also important because if a library is
private, then its include directories are probably private as well. There
are also some include directories I use in a DLL that are only for
implementation details and are not exposed in my interfaces, so it doesn't
make sense for those include directories to be public and transitively get
added to other things.

Any thoughts on this? The logic should already exist for all of this, it
should follow the exact same rules as for libs. So this should be fairly
trivial to implement it seems.

---------
Robert Dailey


On Mon, Nov 7, 2011 at 4:17 PM, Michael Hertling <mhertling at online.de>wrote:

> On 11/06/2011 09:27 AM, Michael Wild wrote:
> > On 11/05/2011 09:59 PM, Michael Hertling wrote:
> >> On 11/02/2011 05:36 PM, Michael Wild wrote:
> >>> Thanks ;-)
> >>>
> >>> Michael
> >>
> >> Just an additional remark: Instead of generating the proxy headers
> >> in CMakeLists.txt, i.e. at configuration time, one might also have
> >> them generated by a custom command, i.e. at build time, which has
> >> the $<CONFIGURATION> expression available. E.g., one might use a
> >> CMake script invoked by the custom command via -P with -DCONFIG=
> >> $<CONFIGURATION>, and within this script, one could do arbitrary
> >> things based on the CONFIG parameter, i.e. linking/copying real
> >> headers, generating proxy headers with or without #ifdefs etc.
> >> In this way, one can gather the entire machinery in the script
> >> and does not need to do the case differentiation in the header
> >> itself, triggered via COMPILE_DEFINITIONS_<CONFIG> properties.
> >> Besides, with the custom command's DEPENDS clause, the actions
> >> can be set up to re-take place if any prerequisite has changed.
> >>
> >> Regards,
> >>
> >> Michael
> >>
> >
> > Indeed, that would be a more sophisticated way of doing it, but it
> > requires maintaining a separate CMake script. Some might consider this
> > to be a drawback, other an advantage as it declutters the CMakeLists.txt
> > file.
>
> IMO, the premier advantage of a CMake script handling configuration-
> specific tasks at build time is that one can do what can be done in
> CMakeLists.txt files only for single-configuration generators:
>
> IF(CONFIG STREQUAL ...)
>    ...
> ELSEIF(CONFIG STREQUAL ...)
>    ...
> ELSE()
>    ...
> ENDIF()
>
> In particular, the ELSE() clause can easily catch configurations - also
> custom ones - one doesn't want to handle specifically. In order to do
> the same in a CMakeLists.txt file and in a generator-independent way,
> one would need to do
>
> FOREACH(i IN LISTS CMAKE_CONFIGURATION_TYPES ITEMS ${CMAKE_BUILD_TYPE})
>    IF(i STREQUAL ...)
>        ...
>    ELSEIF(i STREQUAL ...)
>        ...
>    ELSE()
>        ...
>    ENDIF()
> ENDFOREACH()
>
> and w.r.t. properties like COMPILE_DEFINITIONS_<CONFIG>, one would need
> an additional STRING(TOUPPER ...) because the configurations are named
> "Debug", e.g., while the property must be named *_DEBUG. Moreover, for
> proxy headers, one must essentially still do the case differentiation
> again in the header itself, e.g.
>
> #if defined(CONFIG_DEBUG)
> #include ...
> #elif defined (CONFIG_RELEASE)
> #include ...
> #else
> #include ...
> #endif
>
> using additional definitions CONFIG_*, instead of simply saying
>
> #include "@...@"
>
> in conjunction with CONFIGURE_FILE(... @ONLY) in the CMake script. For
> these reasons, I think that CMake scripts triggered by custom commands
> are generally more expressive in this regard, but of course, the main
> point is that one has the choice.
>
> Regards,
>
> Michael
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120125/65d6daf7/attachment.htm>