|
Notes |
|
|
(0025236)
|
|
Peter Kuemmel
|
|
2011-02-03 11:44
|
|
|
namespace.patch is buggy use namespace-2.patch. |
|
|
|
(0025247)
|
|
Brad King
|
|
2011-02-03 13:50
|
|
Instead of
add_definitions(-DX)
add_library(X x.cpp)
add_library(antiX antiX.cpp)
use
add_library(X x.cpp)
set_property(TARGET X PROPERTY COMPILE_DEFINITIONS X)
add_library(antiX antiX.cpp) |
|
|
|
(0025252)
|
|
Peter Kuemmel
|
|
2011-02-03 15:48
|
|
> set_property(TARGET X PROPERTY COMPILE_DEFINITIONS X)
add_definitions was an example only.
What about include_directories? Even adding a
INCLUDE_DIRECTORIES property wouldn't do the same:
set(x x1)
message(STATUS "x = ${x}")
namespace(nx)
set(x x2)
message(STATUS "x = ${x}")
endnamespace()
message(STATUS "x = ${x}")
Output:
-- x = x1
-- x = x2
-- x = x1
The patch isn't perfect, it's a proposal to see
if there is any chance to get it upstream.
E.g.'namespace' as command name is misleading because
entering the namespace again wouldn't make previously
settings available. A better name must be found.
And cmMakefile::AddNamespace could be merged with
cmMakefile::AddSubDirectory. |
|
|
|
(0025253)
|
|
Brad King
|
|
2011-02-03 15:56
|
|
|
Why not just organize your project with an actual subdirectory? I think the scoping rules are complicated enough. |
|
|
|
(0025254)
|
|
Peter Kuemmel
|
|
2011-02-03 16:08
|
|
I already have subdirectories but I find it much more
elegant and simpler to maintain if I could write all
the identical build rules in one file.
And the scoping rule are so complicated that I (as normal
user) only know that all the settings done in a subdirectory
are only visible in this directory or below.
Adding something like namespace would simplify the scoping rules
because everybody understands the concept of namespaces. |
|
|
|
(0030228)
|
|
David Cole
|
|
2012-08-11 11:09
|
|
Sending old, never assigned issues to the backlog.
(The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...)
If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]
It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
|
|
|
|
(0030467)
|
|
Peter Kuemmel
|
|
2012-08-13 08:41
|
|
|
|
|
(0030773)
|
|
Stephen Kelly
|
|
2012-08-27 07:04
|
|
|
Is this still needed? We have target-scoped include directories since CMake 2.8.8. Are there other commands where directory-scoping is a problem but there is no target-scoped property? We can fill those gaps. |
|
|
|
(0034318)
|
|
Stephen Kelly
|
|
2013-11-02 09:45
|
|
|
We have target_compile_options, target_compile_definitions, and target_include_directories now. I'm sure this is not needed. |
|
|
|
(0034337)
|
|
Peter Kuemmel
|
|
2013-11-03 02:44
|
|
I still like this feature.
Especially when using only one CMake file for several directories the namespace is very comfortable, for instance just use add_definitions() like before.
But it seems all love it to pollute the directory tree CMakeLists.txt file.
So the status is "won't fix", or similar, decided by others. |
|
|
|
(0035996)
|
|
Robert Maynard
|
|
2014-06-02 08:37
|
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|
namespace.patch (33,452) 2011-02-03 11:10