Re: [CMake] debug/optimized include directories
On Friday 04 November 2011, David Cole wrote:
On Wed, Nov 2, 2011 at 8:30 PM, Stephen Kelly steve...@gmail.com wrote:
David Cole wrote:
On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey
rcdai...@gmail.com wrote:
On Tue, Nov 1, 2011 at 3:32 PM, David Cole
david.c...@kitware.com wrote:
Not yet
Meaning there are plans in the works to add such functionality in the
near future?
For now I guess I could actually hard code VS environment variables in
my include directory strings, such as $(Configuration).
There is a feature planned to add per-target include directories (as a
target property). As part of that work, we will probably naturally
also add per-configuration values of that new target property. It is
not yet added as a feature request in the bug tracker, but there are
related ones that I may borrow for the purpose. Stay tuned for more
info, but it is not coming in the next week or two. Hopefully, in time
for 2.8.7, but it depends on timing at this point so no promises.
Hi David,
I'm interested in this feature. I'd like to get it into CMake 2.8.7.
It came up in the recent thread about how Qt5Config.cmake should work:
http://thread.gmane.org/gmane.comp.lib.qt.project.devel/79/focus=226
You mentioned that there are some side-line relevant bugs in the CMake
tracker for this. Could you point me to them? Could you also indicate the
approximate location in the code to look to for starting to work on this
(cmTarget.cxx?).
See these bugs (and probably others, too, but these looked like the
most relevant ones when I searched for include_directories...)
http://public.kitware.com/Bug/view.php?id=1968
http://public.kitware.com/Bug/view.php?id=6269
http://public.kitware.com/Bug/view.php?id=6493
http://public.kitware.com/Bug/view.php?id=8189
I think the main thing we want is a new target property named
INCLUDE_DIRECTORIES - There's already a directory property with that
name; the include_directories command is implemented in terms of that
directory property. Along with that, we will also want
per-configuration variants of the property, similar to the many
existing target properties that have per-config variants.
If you look at the code, you'll see that use of the existing
INCLUDE_DIRECTORIES property triggers a call to
cmMakefile::SetIncludeDirectories, which just saves it in a data
member for later use. You can grep the code for GetIncludeDirectories
for callers, or for just IncludeDirectories to see the direct usage in
cmMakefile.cxx itself.
The interesting bits here are going to be in deciding how to make
these per-target include_directories behave. Should they be additive?
Or should they override the directory-level includes entirely?
I think
get_target_properties(someVar foo INCLUDE_DIRECTORIES)
should return the full list of include directories used for that target.
This would mean that they are not really additive.
Instead, the INCLUDE_DIRECTORIES target property could be initialized from the
directory-property INCLUDE_DIRECTORIES.
Then, to add include dirs, use
set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES ${bar_INCLUDES} )
To set (and ignore any directory-level include dirs):
set_property(TARGET foo PROPERTY INCLUDE_DIRECTORIES ${blub_INCLUDES} )
Alex
--
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
Re: [CMake] debug/optimized include directories
How would it not be additive?
get_target_property() for INCLUDE_DIRECTORIES would return target includes
+ directory includes (that apply to that target, transitively)
I don't know if preprocessor definitions follow this but this is the
behavior I would expect.
-
Robert Dailey
On Mon, Nov 7, 2011 at 11:23 AM, Alexander Neundorf a.neundorf-w...@gmx.net
wrote:
On Friday 04 November 2011, David Cole wrote:
On Wed, Nov 2, 2011 at 8:30 PM, Stephen Kelly steve...@gmail.com
wrote:
David Cole wrote:
On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey
rcdai...@gmail.com wrote:
On Tue, Nov 1, 2011 at 3:32 PM, David Cole
david.c...@kitware.com wrote:
Not yet
Meaning there are plans in the works to add such functionality in the
near future?
For now I guess I could actually hard code VS environment variables
in
my include directory strings, such as $(Configuration).
There is a feature planned to add per-target include directories (as a
target property). As part of that work, we will probably naturally
also add per-configuration values of that new target property. It is
not yet added as a feature request in the bug tracker, but there are
related ones that I may borrow for the purpose. Stay tuned for more
info, but it is not coming in the next week or two. Hopefully, in time
for 2.8.7, but it depends on timing at this point so no promises.
Hi David,
I'm interested in this feature. I'd like to get it into CMake 2.8.7.
It came up in the recent thread about how Qt5Config.cmake should work:
http://thread.gmane.org/gmane.comp.lib.qt.project.devel/79/focus=226
You mentioned that there are some side-line relevant bugs in the CMake
tracker for this. Could you point me to them? Could you also indicate
the
approximate location in the code to look to for starting to work on
this
(cmTarget.cxx?).
See these bugs (and probably others, too, but these looked like the
most relevant ones when I searched for include_directories...)
http://public.kitware.com/Bug/view.php?id=1968
http://public.kitware.com/Bug/view.php?id=6269
http://public.kitware.com/Bug/view.php?id=6493
http://public.kitware.com/Bug/view.php?id=8189
I think the main thing we want is a new target property named
INCLUDE_DIRECTORIES - There's already a directory property with that
name; the include_directories command is implemented in terms of that
directory property. Along with that, we will also want
per-configuration variants of the property, similar to the many
existing target properties that have per-config variants.
If you look at the code, you'll see that use of the existing
INCLUDE_DIRECTORIES property triggers a call to
cmMakefile::SetIncludeDirectories, which just saves it in a data
member for later use. You can grep the code for GetIncludeDirectories
for callers, or for just IncludeDirectories to see the direct usage in
cmMakefile.cxx itself.
The interesting bits here are going to be in deciding how to make
these per-target include_directories behave. Should they be additive?
Or should they override the directory-level includes entirely?
I think
get_target_properties(someVar foo INCLUDE_DIRECTORIES)
should return the full list of include directories used for that target.
This would mean that they are not really additive.
Instead, the INCLUDE_DIRECTORIES target property could be initialized from
the
directory-property INCLUDE_DIRECTORIES.
Then, to add include dirs, use
set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES
${bar_INCLUDES} )
To set (and ignore any directory-level include dirs):
set_property(TARGET foo PROPERTY INCLUDE_DIRECTORIES ${blub_INCLUDES} )
Alex
--
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
Re: [CMake] debug/optimized include directories
I think the main use case for saying non-additive would be useful is:
Having several targets in a given directory, most of which simply use
the directory's property value, which contains several include
directories. Now... have one target where you want to restrict the
include_directories to a single directory value.
I'd expect to be able to support that via setting the target property
to the single directory value, and *replace* the list of several which
come from the directory property. (An override, rather than an
addition.)
People who want to add to the list, would use the APPEND mode of
set_property. People who want to replace the value would use
set_property to set the value.
The even more complicated scenario arises when you support this as a
source-file property, too. And the same source file is used in more
than one target...
On Mon, Nov 7, 2011 at 4:13 PM, Robert Dailey rcdai...@gmail.com wrote:
How would it not be additive?
get_target_property() for INCLUDE_DIRECTORIES would return target includes +
directory includes (that apply to that target, transitively)
I don't know if preprocessor definitions follow this but this is the
behavior I would expect.
-
Robert Dailey
On Mon, Nov 7, 2011 at 11:23 AM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
On Friday 04 November 2011, David Cole wrote:
On Wed, Nov 2, 2011 at 8:30 PM, Stephen Kelly steve...@gmail.com
wrote:
David Cole wrote:
On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey
rcdai...@gmail.com wrote:
On Tue, Nov 1, 2011 at 3:32 PM, David Cole
david.c...@kitware.com wrote:
Not yet
Meaning there are plans in the works to add such functionality in
the
near future?
For now I guess I could actually hard code VS environment variables
in
my include directory strings, such as $(Configuration).
There is a feature planned to add per-target include directories (as
a
target property). As part of that work, we will probably naturally
also add per-configuration values of that new target property. It is
not yet added as a feature request in the bug tracker, but there are
related ones that I may borrow for the purpose. Stay tuned for more
info, but it is not coming in the next week or two. Hopefully, in
time
for 2.8.7, but it depends on timing at this point so no promises.
Hi David,
I'm interested in this feature. I'd like to get it into CMake 2.8.7.
It came up in the recent thread about how Qt5Config.cmake should work:
http://thread.gmane.org/gmane.comp.lib.qt.project.devel/79/focus=226
You mentioned that there are some side-line relevant bugs in the CMake
tracker for this. Could you point me to them? Could you also indicate
the
approximate location in the code to look to for starting to work on
this
(cmTarget.cxx?).
See these bugs (and probably others, too, but these looked like the
most relevant ones when I searched for include_directories...)
http://public.kitware.com/Bug/view.php?id=1968
http://public.kitware.com/Bug/view.php?id=6269
http://public.kitware.com/Bug/view.php?id=6493
http://public.kitware.com/Bug/view.php?id=8189
I think the main thing we want is a new target property named
INCLUDE_DIRECTORIES - There's already a directory property with that
name; the include_directories command is implemented in terms of that
directory property. Along with that, we will also want
per-configuration variants of the property, similar to the many
existing target properties that have per-config variants.
If you look at the code, you'll see that use of the existing
INCLUDE_DIRECTORIES property triggers a call to
cmMakefile::SetIncludeDirectories, which just saves it in a data
member for later use. You can grep the code for GetIncludeDirectories
for callers, or for just IncludeDirectories to see the direct usage in
cmMakefile.cxx itself.
The interesting bits here are going to be in deciding how to make
these per-target include_directories behave. Should they be additive?
Or should they override the directory-level includes entirely?
I think
get_target_properties(someVar foo INCLUDE_DIRECTORIES)
should return the full list of include directories used for that target.
This would mean that they are not really additive.
Instead, the INCLUDE_DIRECTORIES target property could be initialized from
the
directory-property INCLUDE_DIRECTORIES.
Then, to add include dirs, use
set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES
${bar_INCLUDES} )
To set (and ignore any directory-level include dirs):
set_property(TARGET foo PROPERTY INCLUDE_DIRECTORIES ${blub_INCLUDES} )
Alex
--
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
Re: [CMake] debug/optimized include directories
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
Re: [CMake] debug/optimized include directories
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. 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
Re: [CMake] debug/optimized include directories
On Friday 04 November 2011, David Cole wrote: On Fri, Nov 4, 2011 at 12:23 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: ... Looks like the first step to assigning include directories to libraries, so they are used automatically when linking against them. Is this also already in planning ? Alex No, not in planning so much as in wishing. That sounds like another separate target property that may or may not have the same exact value as the INCLUDE_DIRECTORIES property. Not all clients will need all the same include_directories as the target itself... Perhaps an additional property named AUTO_INCLUDE_DIRECTORIES (or something similar that indicates it is automatic) should be used for that purpose. Yes. This should be similar to target_link_libraries() and target_link_libraries( LINK_INTERFACE_LIBRARIES ), right ? It could be named INTERFACE_INCLUDE_DIRECTORIES... It might also need to separate between those include directories used when linking against the library within the same project, and when linking against the library once it has been installed along with its headers. Alex -- 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
Re: [CMake] debug/optimized include directories
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
On 11/02/2011 05:33 PM, Robert Dailey wrote:
Awesome idea, +1
This is probably the best work-around until includes get a target property.
-
Robert Dailey
On Wed, Nov 2, 2011 at 2:43 AM, Michael Wild them...@gmail.com
mailto:them...@gmail.com wrote:
On 11/01/2011 09:49 PM, Robert Dailey wrote:
Well if you need any help coding the feature let me know. I'm already
liking the idea of adding features I want myself into CMake :)
Thanks!
-
Robert Dailey
On Tue, Nov 1, 2011 at 3:47 PM, David Cole david.c...@kitware.com
mailto:david.c...@kitware.com
mailto:david.c...@kitware.com mailto:david.c...@kitware.com
wrote:
On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey
rcdai...@gmail.com mailto:rcdai...@gmail.com
mailto:rcdai...@gmail.com mailto:rcdai...@gmail.com wrote:
On Tue, Nov 1, 2011 at 3:32 PM, David Cole
david.c...@kitware.com mailto:david.c...@kitware.com
mailto:david.c...@kitware.com
mailto:david.c...@kitware.com wrote:
Not yet
Meaning there are plans in the works to add such
functionality in
the near
future?
For now I guess I could actually hard code VS environment
variables in my
include directory strings, such as $(Configuration).
There is a feature planned to add per-target include
directories (as a
target property). As part of that work, we will probably naturally
also add per-configuration values of that new target property.
It is
not yet added as a feature request in the bug tracker, but
there are
related ones that I may borrow for the purpose. Stay tuned
for more
info, but it is not coming in the next week or two. Hopefully,
in time
for 2.8.7, but it depends on timing at this point so no
promises.
For now, your $(Configuration) idea is probably your best bet.
(And
would continue to work even after we implement this feature...)
HTH,
David
Alternatively, if you want to keep it cross-platform and generator
independent, you could use a proxy header which #include's the correct
header using relative or absolute paths using #ifdef's. Probably that
proxy header would need to be generated by configure_file(). You then
would pass the configuration name by setting the
COMPILE_DEFINITIONS_CONFIG property on the directory, target or source
file affected.
Say you have the following layout:
project/
|-- CMakeLists.txt
|-- src/
| |-- frobnicate.c
`-- include/
|-- Debug/
| |-- foo.h
| `-- bar.h
`-- Optimized/
|-- foo.h
`-- bar.h
Now, you want to include the configuration dependent foo.h and bar.h in
frobnicate.c without having to change frobnicate.c itself and might look
like this:
frobnicate.c
#include foo.h
#include bar.h
int main(int argc, char** argv)
{
foo();
bar();
return 0;
}
To get around the issue of needing a configuration-dependent include
path, you could do the following in your CMakeLists.txt file:
CMakeLists.txt:
cmake_minimum_required(VERSION 2.6)
project(frobnicate C)
# loads of stuff
# generate wrapper headers for foo.h and bar.h
foreach(hdr foo.h bar.h)
# find a good include guard name
string(TOUPPER ${hdr} incguard)
string(REGEX REPLACE [^a-zA-Z0-9_] _ incguard
PROXY_HDR_${incguard})
# write the proxy header
file(WRITE ${PROJECT_BINARY_DIR}/include/${hdr}
/* AUTOMATICALLY GENERATED BY CMAKE -- DO NOT EDIT! */
#pragma once
#ifndef ${incguard}
#define ${incguard}
/* if building debug configuration, include Debug/${hdr},
otherwise
Re: [CMake] debug/optimized include directories
On Wed, Nov 2, 2011 at 8:30 PM, Stephen Kelly steve...@gmail.com wrote: David Cole wrote: On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey rcdai...@gmail.com wrote: On Tue, Nov 1, 2011 at 3:32 PM, David Cole david.c...@kitware.com wrote: Not yet Meaning there are plans in the works to add such functionality in the near future? For now I guess I could actually hard code VS environment variables in my include directory strings, such as $(Configuration). There is a feature planned to add per-target include directories (as a target property). As part of that work, we will probably naturally also add per-configuration values of that new target property. It is not yet added as a feature request in the bug tracker, but there are related ones that I may borrow for the purpose. Stay tuned for more info, but it is not coming in the next week or two. Hopefully, in time for 2.8.7, but it depends on timing at this point so no promises. Hi David, I'm interested in this feature. I'd like to get it into CMake 2.8.7. It came up in the recent thread about how Qt5Config.cmake should work: http://thread.gmane.org/gmane.comp.lib.qt.project.devel/79/focus=226 You mentioned that there are some side-line relevant bugs in the CMake tracker for this. Could you point me to them? Could you also indicate the approximate location in the code to look to for starting to work on this (cmTarget.cxx?). See these bugs (and probably others, too, but these looked like the most relevant ones when I searched for include_directories...) http://public.kitware.com/Bug/view.php?id=1968 http://public.kitware.com/Bug/view.php?id=6269 http://public.kitware.com/Bug/view.php?id=6493 http://public.kitware.com/Bug/view.php?id=8189 I think the main thing we want is a new target property named INCLUDE_DIRECTORIES - There's already a directory property with that name; the include_directories command is implemented in terms of that directory property. Along with that, we will also want per-configuration variants of the property, similar to the many existing target properties that have per-config variants. If you look at the code, you'll see that use of the existing INCLUDE_DIRECTORIES property triggers a call to cmMakefile::SetIncludeDirectories, which just saves it in a data member for later use. You can grep the code for GetIncludeDirectories for callers, or for just IncludeDirectories to see the direct usage in cmMakefile.cxx itself. The interesting bits here are going to be in deciding how to make these per-target include_directories behave. Should they be additive? Or should they override the directory-level includes entirely? There is quite some discussion to be had here and some decisions to make. (Which is why I hesitate to promise that this will definitely be ready by 2.8.7...) :-) David Thanks, Steve. -- 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
Re: [CMake] debug/optimized include directories
David, There is a directory-level property for preprocessor definitions too, right? So how do the target properties for preprocessor definitions handle those? I think they are additive aren't they? I would expect the include directories to be additive too. - Robert Dailey On Fri, Nov 4, 2011 at 9:04 AM, David Cole david.c...@kitware.com wrote: On Wed, Nov 2, 2011 at 8:30 PM, Stephen Kelly steve...@gmail.com wrote: David Cole wrote: On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey rcdai...@gmail.com wrote: On Tue, Nov 1, 2011 at 3:32 PM, David Cole david.c...@kitware.com wrote: Not yet Meaning there are plans in the works to add such functionality in the near future? For now I guess I could actually hard code VS environment variables in my include directory strings, such as $(Configuration). There is a feature planned to add per-target include directories (as a target property). As part of that work, we will probably naturally also add per-configuration values of that new target property. It is not yet added as a feature request in the bug tracker, but there are related ones that I may borrow for the purpose. Stay tuned for more info, but it is not coming in the next week or two. Hopefully, in time for 2.8.7, but it depends on timing at this point so no promises. Hi David, I'm interested in this feature. I'd like to get it into CMake 2.8.7. It came up in the recent thread about how Qt5Config.cmake should work: http://thread.gmane.org/gmane.comp.lib.qt.project.devel/79/focus=226 You mentioned that there are some side-line relevant bugs in the CMake tracker for this. Could you point me to them? Could you also indicate the approximate location in the code to look to for starting to work on this (cmTarget.cxx?). See these bugs (and probably others, too, but these looked like the most relevant ones when I searched for include_directories...) http://public.kitware.com/Bug/view.php?id=1968 http://public.kitware.com/Bug/view.php?id=6269 http://public.kitware.com/Bug/view.php?id=6493 http://public.kitware.com/Bug/view.php?id=8189 I think the main thing we want is a new target property named INCLUDE_DIRECTORIES - There's already a directory property with that name; the include_directories command is implemented in terms of that directory property. Along with that, we will also want per-configuration variants of the property, similar to the many existing target properties that have per-config variants. If you look at the code, you'll see that use of the existing INCLUDE_DIRECTORIES property triggers a call to cmMakefile::SetIncludeDirectories, which just saves it in a data member for later use. You can grep the code for GetIncludeDirectories for callers, or for just IncludeDirectories to see the direct usage in cmMakefile.cxx itself. The interesting bits here are going to be in deciding how to make these per-target include_directories behave. Should they be additive? Or should they override the directory-level includes entirely? There is quite some discussion to be had here and some decisions to make. (Which is why I hesitate to promise that this will definitely be ready by 2.8.7...) :-) David Thanks, Steve. -- 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
Re: [CMake] debug/optimized include directories
On Fri, Nov 4, 2011 at 11:16 AM, Robert Dailey rcdai...@gmail.com wrote: David, There is a directory-level property for preprocessor definitions too, right? So how do the target properties for preprocessor definitions handle those? I think they are additive aren't they? I would expect the include directories to be additive too. - Robert Dailey On Fri, Nov 4, 2011 at 9:04 AM, David Cole david.c...@kitware.com wrote: On Wed, Nov 2, 2011 at 8:30 PM, Stephen Kelly steve...@gmail.com wrote: David Cole wrote: On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey rcdai...@gmail.com wrote: On Tue, Nov 1, 2011 at 3:32 PM, David Cole david.c...@kitware.com wrote: Not yet Meaning there are plans in the works to add such functionality in the near future? For now I guess I could actually hard code VS environment variables in my include directory strings, such as $(Configuration). There is a feature planned to add per-target include directories (as a target property). As part of that work, we will probably naturally also add per-configuration values of that new target property. It is not yet added as a feature request in the bug tracker, but there are related ones that I may borrow for the purpose. Stay tuned for more info, but it is not coming in the next week or two. Hopefully, in time for 2.8.7, but it depends on timing at this point so no promises. Hi David, I'm interested in this feature. I'd like to get it into CMake 2.8.7. It came up in the recent thread about how Qt5Config.cmake should work: http://thread.gmane.org/gmane.comp.lib.qt.project.devel/79/focus=226 You mentioned that there are some side-line relevant bugs in the CMake tracker for this. Could you point me to them? Could you also indicate the approximate location in the code to look to for starting to work on this (cmTarget.cxx?). See these bugs (and probably others, too, but these looked like the most relevant ones when I searched for include_directories...) http://public.kitware.com/Bug/view.php?id=1968 http://public.kitware.com/Bug/view.php?id=6269 http://public.kitware.com/Bug/view.php?id=6493 http://public.kitware.com/Bug/view.php?id=8189 I think the main thing we want is a new target property named INCLUDE_DIRECTORIES - There's already a directory property with that name; the include_directories command is implemented in terms of that directory property. Along with that, we will also want per-configuration variants of the property, similar to the many existing target properties that have per-config variants. If you look at the code, you'll see that use of the existing INCLUDE_DIRECTORIES property triggers a call to cmMakefile::SetIncludeDirectories, which just saves it in a data member for later use. You can grep the code for GetIncludeDirectories for callers, or for just IncludeDirectories to see the direct usage in cmMakefile.cxx itself. The interesting bits here are going to be in deciding how to make these per-target include_directories behave. Should they be additive? Or should they override the directory-level includes entirely? There is quite some discussion to be had here and some decisions to make. (Which is why I hesitate to promise that this will definitely be ready by 2.8.7...) I would expect them to be additive. Marcus -- 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
Re: [CMake] debug/optimized include directories
On Friday 04 November 2011, David Cole wrote: On Wed, Nov 2, 2011 at 8:30 PM, Stephen Kelly steve...@gmail.com wrote: David Cole wrote: On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey rcdai...@gmail.com wrote: On Tue, Nov 1, 2011 at 3:32 PM, David Cole david.c...@kitware.com wrote: Not yet Meaning there are plans in the works to add such functionality in the near future? For now I guess I could actually hard code VS environment variables in my include directory strings, such as $(Configuration). There is a feature planned to add per-target include directories (as a target property). As part of that work, we will probably naturally also add per-configuration values of that new target property. It is not yet added as a feature request in the bug tracker, but there are related ones that I may borrow for the purpose. Stay tuned for more info, but it is not coming in the next week or two. Hopefully, in time for 2.8.7, but it depends on timing at this point so no promises. Hi David, I'm interested in this feature. I'd like to get it into CMake 2.8.7. It came up in the recent thread about how Qt5Config.cmake should work: http://thread.gmane.org/gmane.comp.lib.qt.project.devel/79/focus=226 You mentioned that there are some side-line relevant bugs in the CMake tracker for this. Could you point me to them? Could you also indicate the approximate location in the code to look to for starting to work on this (cmTarget.cxx?). See these bugs (and probably others, too, but these looked like the most relevant ones when I searched for include_directories...) http://public.kitware.com/Bug/view.php?id=1968 http://public.kitware.com/Bug/view.php?id=6269 http://public.kitware.com/Bug/view.php?id=6493 http://public.kitware.com/Bug/view.php?id=8189 I think the main thing we want is a new target property named INCLUDE_DIRECTORIES - There's already a directory property with that name; the include_directories command is implemented in terms of that directory property. Along with that, we will also want per-configuration variants of the property, similar to the many existing target properties that have per-config variants. If you look at the code, you'll see that use of the existing INCLUDE_DIRECTORIES property triggers a call to cmMakefile::SetIncludeDirectories, which just saves it in a data member for later use. You can grep the code for GetIncludeDirectories for callers, or for just IncludeDirectories to see the direct usage in cmMakefile.cxx itself. The interesting bits here are going to be in deciding how to make these per-target include_directories behave. Should they be additive? Or should they override the directory-level includes entirely? There is quite some discussion to be had here and some decisions to make. (Which is why I hesitate to promise that this will definitely be ready by 2.8.7...) Looks like the first step to assigning include directories to libraries, so they are used automatically when linking against them. Is this also already in planning ? Alex -- 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
Re: [CMake] debug/optimized include directories
On Fri, Nov 4, 2011 at 12:23 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Friday 04 November 2011, David Cole wrote: On Wed, Nov 2, 2011 at 8:30 PM, Stephen Kelly steve...@gmail.com wrote: David Cole wrote: On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey rcdai...@gmail.com wrote: On Tue, Nov 1, 2011 at 3:32 PM, David Cole david.c...@kitware.com wrote: Not yet Meaning there are plans in the works to add such functionality in the near future? For now I guess I could actually hard code VS environment variables in my include directory strings, such as $(Configuration). There is a feature planned to add per-target include directories (as a target property). As part of that work, we will probably naturally also add per-configuration values of that new target property. It is not yet added as a feature request in the bug tracker, but there are related ones that I may borrow for the purpose. Stay tuned for more info, but it is not coming in the next week or two. Hopefully, in time for 2.8.7, but it depends on timing at this point so no promises. Hi David, I'm interested in this feature. I'd like to get it into CMake 2.8.7. It came up in the recent thread about how Qt5Config.cmake should work: http://thread.gmane.org/gmane.comp.lib.qt.project.devel/79/focus=226 You mentioned that there are some side-line relevant bugs in the CMake tracker for this. Could you point me to them? Could you also indicate the approximate location in the code to look to for starting to work on this (cmTarget.cxx?). See these bugs (and probably others, too, but these looked like the most relevant ones when I searched for include_directories...) http://public.kitware.com/Bug/view.php?id=1968 http://public.kitware.com/Bug/view.php?id=6269 http://public.kitware.com/Bug/view.php?id=6493 http://public.kitware.com/Bug/view.php?id=8189 I think the main thing we want is a new target property named INCLUDE_DIRECTORIES - There's already a directory property with that name; the include_directories command is implemented in terms of that directory property. Along with that, we will also want per-configuration variants of the property, similar to the many existing target properties that have per-config variants. If you look at the code, you'll see that use of the existing INCLUDE_DIRECTORIES property triggers a call to cmMakefile::SetIncludeDirectories, which just saves it in a data member for later use. You can grep the code for GetIncludeDirectories for callers, or for just IncludeDirectories to see the direct usage in cmMakefile.cxx itself. The interesting bits here are going to be in deciding how to make these per-target include_directories behave. Should they be additive? Or should they override the directory-level includes entirely? There is quite some discussion to be had here and some decisions to make. (Which is why I hesitate to promise that this will definitely be ready by 2.8.7...) Looks like the first step to assigning include directories to libraries, so they are used automatically when linking against them. Is this also already in planning ? Alex No, not in planning so much as in wishing. That sounds like another separate target property that may or may not have the same exact value as the INCLUDE_DIRECTORIES property. Not all clients will need all the same include_directories as the target itself... Perhaps an additional property named AUTO_INCLUDE_DIRECTORIES (or something similar that indicates it is automatic) should be used for that purpose. -- 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
Re: [CMake] debug/optimized include directories
Thanks for volunteering for this! - Robert Dailey On Wed, Nov 2, 2011 at 7:30 PM, Stephen Kelly steve...@gmail.com wrote: David Cole wrote: On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey rcdai...@gmail.com wrote: On Tue, Nov 1, 2011 at 3:32 PM, David Cole david.c...@kitware.com wrote: Not yet Meaning there are plans in the works to add such functionality in the near future? For now I guess I could actually hard code VS environment variables in my include directory strings, such as $(Configuration). There is a feature planned to add per-target include directories (as a target property). As part of that work, we will probably naturally also add per-configuration values of that new target property. It is not yet added as a feature request in the bug tracker, but there are related ones that I may borrow for the purpose. Stay tuned for more info, but it is not coming in the next week or two. Hopefully, in time for 2.8.7, but it depends on timing at this point so no promises. Hi David, I'm interested in this feature. I'd like to get it into CMake 2.8.7. It came up in the recent thread about how Qt5Config.cmake should work: http://thread.gmane.org/gmane.comp.lib.qt.project.devel/79/focus=226 You mentioned that there are some side-line relevant bugs in the CMake tracker for this. Could you point me to them? Could you also indicate the approximate location in the code to look to for starting to work on this (cmTarget.cxx?). Thanks, Steve. -- 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
Re: [CMake] debug/optimized include directories
Awesome idea, +1
This is probably the best work-around until includes get a target property.
-
Robert Dailey
On Wed, Nov 2, 2011 at 2:43 AM, Michael Wild them...@gmail.com wrote:
On 11/01/2011 09:49 PM, Robert Dailey wrote:
Well if you need any help coding the feature let me know. I'm already
liking the idea of adding features I want myself into CMake :)
Thanks!
-
Robert Dailey
On Tue, Nov 1, 2011 at 3:47 PM, David Cole david.c...@kitware.com
mailto:david.c...@kitware.com wrote:
On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey rcdai...@gmail.com
mailto:rcdai...@gmail.com wrote:
On Tue, Nov 1, 2011 at 3:32 PM, David Cole david.c...@kitware.com
mailto:david.c...@kitware.com wrote:
Not yet
Meaning there are plans in the works to add such functionality in
the near
future?
For now I guess I could actually hard code VS environment
variables in my
include directory strings, such as $(Configuration).
There is a feature planned to add per-target include directories (as
a
target property). As part of that work, we will probably naturally
also add per-configuration values of that new target property. It is
not yet added as a feature request in the bug tracker, but there are
related ones that I may borrow for the purpose. Stay tuned for more
info, but it is not coming in the next week or two. Hopefully, in
time
for 2.8.7, but it depends on timing at this point so no promises.
For now, your $(Configuration) idea is probably your best bet. (And
would continue to work even after we implement this feature...)
HTH,
David
Alternatively, if you want to keep it cross-platform and generator
independent, you could use a proxy header which #include's the correct
header using relative or absolute paths using #ifdef's. Probably that
proxy header would need to be generated by configure_file(). You then
would pass the configuration name by setting the
COMPILE_DEFINITIONS_CONFIG property on the directory, target or source
file affected.
Say you have the following layout:
project/
|-- CMakeLists.txt
|-- src/
| |-- frobnicate.c
`-- include/
|-- Debug/
| |-- foo.h
| `-- bar.h
`-- Optimized/
|-- foo.h
`-- bar.h
Now, you want to include the configuration dependent foo.h and bar.h in
frobnicate.c without having to change frobnicate.c itself and might look
like this:
frobnicate.c
#include foo.h
#include bar.h
int main(int argc, char** argv)
{
foo();
bar();
return 0;
}
To get around the issue of needing a configuration-dependent include
path, you could do the following in your CMakeLists.txt file:
CMakeLists.txt:
cmake_minimum_required(VERSION 2.6)
project(frobnicate C)
# loads of stuff
# generate wrapper headers for foo.h and bar.h
foreach(hdr foo.h bar.h)
# find a good include guard name
string(TOUPPER ${hdr} incguard)
string(REGEX REPLACE [^a-zA-Z0-9_] _ incguard
PROXY_HDR_${incguard})
# write the proxy header
file(WRITE ${PROJECT_BINARY_DIR}/include/${hdr}
/* AUTOMATICALLY GENERATED BY CMAKE -- DO NOT EDIT! */
#pragma once
#ifndef ${incguard}
#define ${incguard}
/* if building debug configuration, include Debug/${hdr},
otherwise Optimized/${hdr} */
#if defined(CONFIG_DEBUG)
# include \Debug/${hdr}\
#else
# include \Optimized/${hdr}\
#endif
#endif
)
endforeach()
# set up the definitions for the switch yard
set_directory_properties(PROPERTIES
COMPILE_DEFINITIONS_DEBUG CONFIG_DEBUG
COMPILE_DEFINITIONS_RELEASE CONFIG_RELEASE
COMPILE_DEFINITIONS_RELWITHDEBINFO CONFIG_RELWITHDEBINFO
COMPILE_DEFINITIONS_MINSIZEREL CONFIG_MINSIZE_REL)
# set up the include directories so our proxy headers and the actual
# headers can be found by the preprocessor
include_directories(
${PROJECT_BINARY_DIR}/include
${PROJECT_SOURCE_DIR}/include)
add_executable(frobnicate frobnicate.c)
HTH
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
--
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
Re: [CMake] debug/optimized include directories
Thanks ;-)
Michael
On 11/02/2011 05:33 PM, Robert Dailey wrote:
Awesome idea, +1
This is probably the best work-around until includes get a target property.
-
Robert Dailey
On Wed, Nov 2, 2011 at 2:43 AM, Michael Wild them...@gmail.com
mailto:them...@gmail.com wrote:
On 11/01/2011 09:49 PM, Robert Dailey wrote:
Well if you need any help coding the feature let me know. I'm already
liking the idea of adding features I want myself into CMake :)
Thanks!
-
Robert Dailey
On Tue, Nov 1, 2011 at 3:47 PM, David Cole david.c...@kitware.com
mailto:david.c...@kitware.com
mailto:david.c...@kitware.com mailto:david.c...@kitware.com
wrote:
On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey
rcdai...@gmail.com mailto:rcdai...@gmail.com
mailto:rcdai...@gmail.com mailto:rcdai...@gmail.com wrote:
On Tue, Nov 1, 2011 at 3:32 PM, David Cole
david.c...@kitware.com mailto:david.c...@kitware.com
mailto:david.c...@kitware.com
mailto:david.c...@kitware.com wrote:
Not yet
Meaning there are plans in the works to add such
functionality in
the near
future?
For now I guess I could actually hard code VS environment
variables in my
include directory strings, such as $(Configuration).
There is a feature planned to add per-target include
directories (as a
target property). As part of that work, we will probably naturally
also add per-configuration values of that new target property.
It is
not yet added as a feature request in the bug tracker, but
there are
related ones that I may borrow for the purpose. Stay tuned
for more
info, but it is not coming in the next week or two. Hopefully,
in time
for 2.8.7, but it depends on timing at this point so no
promises.
For now, your $(Configuration) idea is probably your best bet.
(And
would continue to work even after we implement this feature...)
HTH,
David
Alternatively, if you want to keep it cross-platform and generator
independent, you could use a proxy header which #include's the correct
header using relative or absolute paths using #ifdef's. Probably that
proxy header would need to be generated by configure_file(). You then
would pass the configuration name by setting the
COMPILE_DEFINITIONS_CONFIG property on the directory, target or source
file affected.
Say you have the following layout:
project/
|-- CMakeLists.txt
|-- src/
| |-- frobnicate.c
`-- include/
|-- Debug/
| |-- foo.h
| `-- bar.h
`-- Optimized/
|-- foo.h
`-- bar.h
Now, you want to include the configuration dependent foo.h and bar.h in
frobnicate.c without having to change frobnicate.c itself and might look
like this:
frobnicate.c
#include foo.h
#include bar.h
int main(int argc, char** argv)
{
foo();
bar();
return 0;
}
To get around the issue of needing a configuration-dependent include
path, you could do the following in your CMakeLists.txt file:
CMakeLists.txt:
cmake_minimum_required(VERSION 2.6)
project(frobnicate C)
# loads of stuff
# generate wrapper headers for foo.h and bar.h
foreach(hdr foo.h bar.h)
# find a good include guard name
string(TOUPPER ${hdr} incguard)
string(REGEX REPLACE [^a-zA-Z0-9_] _ incguard
PROXY_HDR_${incguard})
# write the proxy header
file(WRITE ${PROJECT_BINARY_DIR}/include/${hdr}
/* AUTOMATICALLY GENERATED BY CMAKE -- DO NOT EDIT! */
#pragma once
#ifndef ${incguard}
#define ${incguard}
/* if building debug configuration, include Debug/${hdr},
otherwise Optimized/${hdr} */
#if defined(CONFIG_DEBUG)
# include \Debug/${hdr}\
#else
# include \Optimized/${hdr}\
#endif
#endif
)
endforeach()
# set up the definitions for the switch yard
set_directory_properties(PROPERTIES
COMPILE_DEFINITIONS_DEBUG CONFIG_DEBUG
COMPILE_DEFINITIONS_RELEASE CONFIG_RELEASE
COMPILE_DEFINITIONS_RELWITHDEBINFO CONFIG_RELWITHDEBINFO
COMPILE_DEFINITIONS_MINSIZEREL CONFIG_MINSIZE_REL)
# set up the include directories so our proxy headers and the actual
# headers can be found by the preprocessor
include_directories(
${PROJECT_BINARY_DIR}/include
${PROJECT_SOURCE_DIR}/include)
add_executable(frobnicate frobnicate.c)
HTH
Michael
--
Powered by www.kitware.com http://www.kitware.com
Visit other
Re: [CMake] debug/optimized include directories
David Cole wrote: On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey rcdai...@gmail.com wrote: On Tue, Nov 1, 2011 at 3:32 PM, David Cole david.c...@kitware.com wrote: Not yet Meaning there are plans in the works to add such functionality in the near future? For now I guess I could actually hard code VS environment variables in my include directory strings, such as $(Configuration). There is a feature planned to add per-target include directories (as a target property). As part of that work, we will probably naturally also add per-configuration values of that new target property. It is not yet added as a feature request in the bug tracker, but there are related ones that I may borrow for the purpose. Stay tuned for more info, but it is not coming in the next week or two. Hopefully, in time for 2.8.7, but it depends on timing at this point so no promises. Hi David, I'm interested in this feature. I'd like to get it into CMake 2.8.7. It came up in the recent thread about how Qt5Config.cmake should work: http://thread.gmane.org/gmane.comp.lib.qt.project.devel/79/focus=226 You mentioned that there are some side-line relevant bugs in the CMake tracker for this. Could you point me to them? Could you also indicate the approximate location in the code to look to for starting to work on this (cmTarget.cxx?). Thanks, Steve. -- 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
Re: [CMake] debug/optimized include directories
Not yet On Tue, Nov 1, 2011 at 4:30 PM, Robert Dailey rcdai...@gmail.com wrote: When generating for Visual Studio, is there a way to make projects in debug configuration have a different set of include directories from the release configuration? - Robert Dailey -- 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
Re: [CMake] debug/optimized include directories
On Tue, Nov 1, 2011 at 3:32 PM, David Cole david.c...@kitware.com wrote: Not yet Meaning there are plans in the works to add such functionality in the near future? For now I guess I could actually hard code VS environment variables in my include directory strings, such as $(Configuration). -- 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
Re: [CMake] debug/optimized include directories
On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey rcdai...@gmail.com wrote: On Tue, Nov 1, 2011 at 3:32 PM, David Cole david.c...@kitware.com wrote: Not yet Meaning there are plans in the works to add such functionality in the near future? For now I guess I could actually hard code VS environment variables in my include directory strings, such as $(Configuration). There is a feature planned to add per-target include directories (as a target property). As part of that work, we will probably naturally also add per-configuration values of that new target property. It is not yet added as a feature request in the bug tracker, but there are related ones that I may borrow for the purpose. Stay tuned for more info, but it is not coming in the next week or two. Hopefully, in time for 2.8.7, but it depends on timing at this point so no promises. For now, your $(Configuration) idea is probably your best bet. (And would continue to work even after we implement this feature...) HTH, David -- 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
Re: [CMake] debug/optimized include directories
Well if you need any help coding the feature let me know. I'm already liking the idea of adding features I want myself into CMake :) Thanks! - Robert Dailey On Tue, Nov 1, 2011 at 3:47 PM, David Cole david.c...@kitware.com wrote: On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey rcdai...@gmail.com wrote: On Tue, Nov 1, 2011 at 3:32 PM, David Cole david.c...@kitware.com wrote: Not yet Meaning there are plans in the works to add such functionality in the near future? For now I guess I could actually hard code VS environment variables in my include directory strings, such as $(Configuration). There is a feature planned to add per-target include directories (as a target property). As part of that work, we will probably naturally also add per-configuration values of that new target property. It is not yet added as a feature request in the bug tracker, but there are related ones that I may borrow for the purpose. Stay tuned for more info, but it is not coming in the next week or two. Hopefully, in time for 2.8.7, but it depends on timing at this point so no promises. For now, your $(Configuration) idea is probably your best bet. (And would continue to work even after we implement this feature...) HTH, David -- 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
