[cmake-developers] [CMake 0014325]: Cmake parser rejects empty items list in target_include_directories
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14325
==
Reported By:Gregor Jasny
Assigned To:
==
Project:CMake
Issue ID: 14325
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2013-07-31 05:38 EDT
Last Modified: 2013-07-31 05:38 EDT
==
Summary:Cmake parser rejects empty items list in
target_include_directories
Description:
I wonder if cmake should be able to parse the following project file:
cmake_minimum_required(VERSION 2.8.11)
project(Foo)
add_library(mylib STATIC mylib.c)
#set(a a)
target_include_directories(mylib PUBLIC ${a})
The help text for target_include_directories shows the following syntax:
target_include_directories(target [BEFORE
INTERFACE|PUBLIC|PRIVATE [items1...]
[INTERFACE|PUBLIC|PRIVATE [items2...] ...])
So I would consider the item list in the [] brackets as optional.
==
Issue History
Date ModifiedUsername FieldChange
==
2013-07-31 05:38 Gregor Jasny New Issue
==
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
Alexander Neundorf wrote: Comments ? If possible, I'd like to get that into 2.8.12. Note that even in KDE there isn't consensus on whether to rely on this in the non-short term: http://thread.gmane.org/gmane.comp.kde.devel.core/80233/focus=80241 I don't see any particular reason to get it into 2.8.12. From the KDE perspective, I think it would be more useful to get a CMake version with ALIAS targets and double-colons-means-IMPORTED. My preference is for 2.8.12 to be out soon and get those features into 2.8.13. When do you want to create 2.8.12 RC1? 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
Brad King wrote: On 07/30/2013 09:46 AM, Stephen Kelly wrote: That is, parameters to install(TARGETS) are evaluated at export time, and otherwise the contents of the property are reproduced verbatim. Yes, I think this makes sense. The install rules run as part of the current project's build just like custom commands, so it makes sense to evaluate generator expressions immediately. However, the implementation may be a bit complicated because now cmake_install.cmake script code will have to branch on BUILD_TYPE to pick which install rule to run. There is already infrastructure for this to support the CONFIGURATIONS option of install(TARGETS) so maybe it is okay. I think two things are being confused here. One is the DESTINATION for things that are installed by the current command. Eg: install(TARGETS foo RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib ) install(FILES foo.h DESTINATION include ) The bug report is about adding genex support to those destinations. The new feature is install(TARGETS foo INCLUDES DESTINATION include ) which does not result in installing anything to 'include/', but only populates a property. This is quite separate to what you describe above. I propose that we deal with what you describe above after 2.8.12. For supporting generator expressions in install(TARGETS foo INCLUDES DESTINATION include ) I've pushed a INCLUDES-DESTINATION-partial-eval topic to my clone with some ideas for it. Please let me know what you think. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014326]: VS2012 generator ignores /SUBSYSTEM:WNDOWS
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14326
==
Reported By:Soeren Freudiger
Assigned To:
==
Project:CMake
Issue ID: 14326
Category: (No Category)
Reproducibility:always
Severity: minor
Priority: high
Status: new
==
Date Submitted: 2013-07-31 08:02 EDT
Last Modified: 2013-07-31 08:02 EDT
==
Summary:VS2012 generator ignores /SUBSYSTEM:WNDOWS
Description:
We define for all Win and MFC projects the Subystem with /SUBSYSTEM:WINDOWS.
This works very well for VS2003/2005 and 2008 (2010 we did not try).
But for VS2012 this flag is ignored by cmake. Only at
add_executable( MY_TARGET WIN32 ${MY_files} )
we obtain the correct flag.
Otherwise we find
/CONSOLE:CONSOLE5,01
inside the link options...
Steps to Reproduce:
first we add the link option with:
set_target_properties( MY_TARGET PROPERTIES LINK_FLAGS_DEBUG
/SUBSYSTEM:WINDOWS)
then we set
set(CMAKE_MFC_FLAG 1) http://www.cmake.org/Bug/view.php?id=1 for static the
static MFC library
and
add_library( ${project_name} SHARED ${_files} )
Additional Information:
the result in the vcxproj is:
subsystemconsole/subsystem
At VS2008 we have something like:
AdditionalOptions= /machine:X86 /debug /swaprun:net /LIBPATH:E:/DitecLibs/Lib
nafxcwd.lib /SUBSYSTEM:WINDOWS
and that works fine.
I think the parser somehow ignores the SUBSYSTEM command. Is that the point?
==
Issue History
Date ModifiedUsername FieldChange
==
2013-07-31 08:02 Soeren FreudigerNew Issue
==
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
On 07/31/2013 06:44 AM, Stephen Kelly wrote: Note that even in KDE there isn't consensus on whether to rely on this in the non-short term: http://thread.gmane.org/gmane.comp.kde.devel.core/80233/focus=80241 I don't see any particular reason to get it into 2.8.12. From the KDE perspective, I think it would be more useful to get a CMake version with ALIAS targets and double-colons-means-IMPORTED. My preference is for 2.8.12 to be out soon and get those features into 2.8.13. I agree. Several of Steve's topics are more mature than the one proposed here and he's waiting until after 2.8.12 for them. When do you want to create 2.8.12 RC1? As soon as things are polished up on the dashboard and we have time to initiate the RC cycle. Hopefully early next week. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
On 07/31/2013 07:53 AM, Stephen Kelly wrote: I think two things are being confused here. One is the DESTINATION for things that are installed by the current command. Eg: install(TARGETS foo RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib ) install(FILES foo.h DESTINATION include ) The bug report is about adding genex support to those destinations. Yes, it's also the one that started this thread. Do we agree that full generate-time evaluation is appropriate for these? If so then the implementation will require BUILD_TYPE conditional blocks in generated cmake_install.cmake files. I propose that we deal with what you describe above after 2.8.12. Yes, definately. For supporting generator expressions in install(TARGETS foo INCLUDES DESTINATION include ) I've pushed a INCLUDES-DESTINATION-partial-eval topic to my clone with some ideas for it. Please let me know what you think. Are you proposing this for inclusion in 2.8.12? IMO it can wait along with the rest. I forgot, which config-related generator expressions on imported targets honor MAP_IMPORTED_CONFIG_CONFIG? What is the behavior when a not-allowed expression like STREQUAL is used? Does it produce an error message? -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
Brad King wrote:
I've pushed a INCLUDES-DESTINATION-partial-eval topic to my clone with
some ideas for it. Please let me know what you think.
Are you proposing this for inclusion in 2.8.12?
Yes.
IMO it can wait along with the rest.
As INCLUDES DESTINATION is already in master, that would be a behavior
change, and probably need a policy. Currently if you use
install(TARGETS foo EXPORT fooTargets
INCLUDES DESTINATION $INSTALL_PREFIX/include/$STREQUAL:foo,bar
)
the result in fooTargets.cmake is
INTERFACE_INCLUDE_DIRECTORIES
${_IMPORT_PREFIX}/include/$STREQUAL:foo,bar
if the genex is evaluated at export time in a follow-up release, the result
would instead be
INTERFACE_INCLUDE_DIRECTORIES
${_IMPORT_PREFIX}/include/0
So, I think for the case of INCLUDES DESTINATION, we can either decide and
fix it now, or revert the change adding it for 2.8.12.
I forgot, which config-related generator expressions on imported
targets honor MAP_IMPORTED_CONFIG_CONFIG?
The $CONFIG:cfg expression should always process those, if used on any of
the target properties used for the interface.
What is the behavior when a not-allowed expression like
STREQUAL is used? Does it produce an error message?
In master the STREQUAL is reproduced verbatim. In my topic it is evaluated
at export time.
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
Brad King wrote: The bug report is about adding genex support to those destinations. Yes, it's also the one that started this thread. Do we agree that full generate-time evaluation is appropriate for these? If so then the implementation will require BUILD_TYPE conditional blocks in generated cmake_install.cmake files. I don't know yet. I haven't looked into the generated cmake_install.cmake files. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] target_include_directories and empty lists
On 07/31/2013 09:17 AM, Stephen Kelly wrote:
On 07/31/2013 03:13 PM, Brad King wrote:
On 07/31/2013 09:11 AM, Stephen Kelly wrote:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=452e58525bb1656df0a169c8a047c25837caa4cf
[snip]
Docs: Document that target property commands require at least one item.
[snip]
- INTERFACE|PUBLIC|PRIVATE [items1...]\n
+ INTERFACE|PUBLIC|PRIVATE item [items1...]\n
What is wrong with an empty list of items?
I didn't see any reason not to be 'strict'.
The use case in issue 14325 is very common and IMO expected behavior.
In fact throughout the reviews I assumed this was allowed based not
only on the documentation but what I thought we intended. What about
the tll() version?
Changing that behavior is something I'd recommend deferring to after
2.8.12 if you want to change it. I don't feel extremely strongly about
keeping it strict.
How intrusive is the change? I don't want to make people wait for
2.8.13 just to avoid creating conditions like
if(mylist)
target_include_directories(... PUBLIC ${mylist})
endif()
They will end up being pervasive in code examples and stick around
far longer than we expect. Just look at the use of the ancient
and completely unnecessary ARGS parameter to add_custom_command.
-Brad
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
On 07/31/2013 09:25 AM, Stephen Kelly wrote: As INCLUDES DESTINATION is already in master, that would be a behavior change, and probably need a policy. Technically that will be true for the real DESTINATION values too but I doubt anyone has installed to a path with $ in it. Since INCLUDES DESTINATION populates a property that supports generator expressions they are likely to be used. I see your point. So, I think for the case of INCLUDES DESTINATION, we can either decide and fix it now, or revert the change adding it for 2.8.12. Let's try to decide now and revert as a last resort. So the only reason we need partial evaluation is to leave configuration-dependent sub-expressions untouched since the configuration is not known until generation of the consumer? I think the partial evaluation should work by traversing the expression tree and collapsing sub-tree that does not depend on the configuration into a leaf node with a constant value. Alternatively we could generate an error if any config-dependent expressions are found in INCLUDES DESTINATION and otherwise do full evaluation. That way we can decide on the partial evaluation semantics later. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories and empty lists
Brad King wrote:
What about the tll() version?
target_link_libraries(foo PRIVATE )
seems to not be an error with master already.
Changing that behavior is something I'd recommend deferring to after
2.8.12 if you want to change it. I don't feel extremely strongly about
keeping it strict.
How intrusive is the change?
It might be as simple as
diff --git a/Source/cmTargetPropCommandBase.cxx
b/Source/cmTargetPropCommandBase.cxx
index 287ce46..37aa604 100644
--- a/Source/cmTargetPropCommandBase.cxx
+++ b/Source/cmTargetPropCommandBase.cxx
@@ -19,7 +19,7 @@ bool cmTargetPropCommandBase
::HandleArguments(std::vectorstd::string const args, const char *prop,
ArgumentFlags flags)
{
- if(args.size() 3)
+ if(args.size() 2)
{
this-SetError(called with incorrect number of arguments);
return false;
@@ -53,7 +53,7 @@ bool cmTargetPropCommandBase
if ((flags PROCESS_SYSTEM) args[argIndex] == SYSTEM)
{
-if (args.size() 4)
+if (args.size() 3)
{
this-SetError(called with incorrect number of arguments);
return false;
@@ -65,7 +65,7 @@ bool cmTargetPropCommandBase
bool prepend = false;
if ((flags PROCESS_BEFORE) args[argIndex] == BEFORE)
{
-if (args.size() 4)
+if (args.size() 3)
{
this-SetError(called with incorrect number of arguments);
return false;
... but I haven't tried most of the arg combinations.
I don't want to make people wait for
2.8.13 just to avoid creating conditions like
if(mylist)
target_include_directories(... PUBLIC ${mylist})
endif()
Ok, I'll add a test for the above patch and submit that.
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindBacktrace.cmake
On 07/29/2013 12:38 PM, Vadim Zhukov wrote: 2013/7/29 Brad King brad.k...@kitware.com: Let's complete the add-cmake_reset_check_state topic first and then you can rebase the find_backtrace topic on it to use the feature. The former looks good but we'll let it run through the dashboards tonight first. Thank you for looking in. I'll follow this plan then. The dependency is now in master so please rebase find_backtrace on that so you can use the reset feature. Thanks, -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories and empty lists
On 07/31/2013 10:01 AM, Stephen Kelly wrote: Ok, I'll add a test for the above patch and submit that. Great, thanks! -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
Brad King wrote:
So, I think for the case of INCLUDES DESTINATION, we can either decide
and fix it now, or revert the change adding it for 2.8.12.
Let's try to decide now and revert as a last resort.
So the only reason we need partial evaluation is to leave
configuration-dependent sub-expressions untouched since the
configuration is not known until generation of the consumer?
Yes, I think that is the case.
Includes are not generally different files for debug/release as the
preprocessor is generally used instead where needed. However, let's assume
that for the debug config we install a foo_debug.h, and otherwise not.
To get more concrete, here's some cases I could think of:
A) I want to install all includes to
set(config_suffix $$CONFIG:Debug:debug$NOT:$CONFIG:Debug:release)
INCLUDES DESTINATION $INSTALL_PREFIX/include/${config_suffix}
and for consumers of the target to get either the 'debug' or the 'release'
include directory.
I would use
install(FILES ${files}
DESTINATION include/${config_suffix})
(when that works) to install the files.
B) I only want to install the foo_debug.h to a special location
install(FILES ${files}
DESTINATION include)
install(FILES foo_debug.h
DESTINATION include/debug
CONFIGURATIONS Debug
)
INCLUDES DESTINATION
include;$$CONFIG:Debug:$INSTALL_PREFIX/include/debug
So that consumers get both include directories. This probably works already
with master.
C) As B, but with target-named include paths
install(FILES ${foo_files}
DESTINATION include/foo)
install(FILES ${bar_files}
DESTINATION include/bar)
install(FILES foo_debug.h
DESTINATION include/foo/debug
CONFIGURATIONS Debug
)
set(basic_path $INSTALL_PREFIX/include/$TARGET_PROPERTY:NAME)
INCLUDES DESTINATION
${basic_path}
$$CONFIG:Debug:${basic_path}/debug
This does not work with master. However, there is a workaround.
target_include_directories(foo INTERFACE
include/foo
$$CONFIG:Debug:$INSTALL_PREFIX/include/foo/debug
)
ie, not using the INCLUDES DESTINATION feature, which is 'just' a
convenience for the 'common case'.
I think the partial evaluation should work by traversing
the expression tree and collapsing sub-tree that does not
depend on the configuration into a leaf node with a constant
value.
Alternatively we could generate an error if any config-dependent
expressions are found in INCLUDES DESTINATION and otherwise
do full evaluation. That way we can decide on the partial
evaluation semantics later.
Yes, such an error would be quite easy to generate, as that fact is already
recorded. I considered that and decided not to implement it because the bug
report specifically wanted config support. However, that was for libraries,
not includes. Config sensitive dirs are likely more common for libraries
than includes, so actually I think it would be fine to make that an error
and always do full evaluation.
I've pushed INCLUDES-DESTINATION-no-config to my clone with an
implementation. Can I merge it to next?
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
On 07/31/2013 11:05 AM, Stephen Kelly wrote:
Config sensitive dirs are likely more common for libraries
than includes, so actually I think it would be fine to make that an error
and always do full evaluation.
To clarify, the no-config rule is for INCLUDES DESTINATION only, but full
with-config evaluation will be allowed for a real DESTINATION. The
config can be honored for file destinations. For targets we generate
a per-config IMPORTED_LOCATION_CONFIG anyway. We will wait for after
2.8.12 for the file destination generator expressions.
I've pushed INCLUDES-DESTINATION-no-config to my clone with an
implementation. Can I merge it to next?
Yes, but one comment first:
+ if (cge-GetHadContextSensitiveCondition())
+{
+cmMakefile* mf = target-GetMakefile();
+cmOStringStream e;
+e Target \ target-GetName() \ is installed with
+INCLUDES DESTINATION set to a configuration sensitive path. This is
Does context sensitive condition ever mean something other than
configuration sensitive? If so then users may produce a case that
triggers this error in a confusing manner.
-Brad
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
Brad King wrote:
On 07/31/2013 11:05 AM, Stephen Kelly wrote:
Config sensitive dirs are likely more common for libraries
than includes, so actually I think it would be fine to make that an error
and always do full evaluation.
To clarify, the no-config rule is for INCLUDES DESTINATION only, but full
with-config evaluation will be allowed for a real DESTINATION. The
config can be honored for file destinations. For targets we generate
a per-config IMPORTED_LOCATION_CONFIG anyway. We will wait for after
2.8.12 for the file destination generator expressions.
Right.
I've pushed INCLUDES-DESTINATION-no-config to my clone with an
implementation. Can I merge it to next?
Yes, but one comment first:
+ if (cge-GetHadContextSensitiveCondition())
+{
+cmMakefile* mf = target-GetMakefile();
+cmOStringStream e;
+e Target \ target-GetName() \ is installed with
+INCLUDES DESTINATION set to a configuration sensitive path. This is
Does context sensitive condition ever mean something other than
configuration sensitive? If so then users may produce a case that
triggers this error in a confusing manner.
Yes, is also means that TARGET_POLICY was used, or a
LINK_INTERFACE_DEPENDENT_{BOOL,STRING} property was used in the generator
expression.
In the case of the target policy, it makes sense to error on this because
there is no point in changing the property based on the policy setting of
the consumer of the IMPORTED target.
For LINK_INTERFACE_DEPENDENT_STRING properties it is a bit unfortunate,
because we can't use the QT_MAJOR_VERSION target property and install to
either include/Qt4Based or include/Qt5Based depending on which version we're
installing for.
However, that is still easily possible with target_include_directories.
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014327]: CMAKE_CONFIG_POSTFIX For Executables
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14327
==
Reported By:Ryan H. Kawicki
Assigned To:
==
Project:CMake
Issue ID: 14327
Category: CMake
Reproducibility:always
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2013-07-31 14:32 EDT
Last Modified: 2013-07-31 14:32 EDT
==
Summary:CMAKE_CONFIG_POSTFIX For Executables
Description:
According to the documentation, CMAKE_CONFIG_POSTFIX does not apply
executables due to legacy reasons. It would be nice if this also applied to
executables and then use the policy system to enforce OLD or NEW.
Steps to Reproduce:
SET(CMAKE_DEBUG_POSTFIX D
CACHE STRING
Adds a debug postfix symbol, usually \D\ on Windows.
FORCE)
# the above does not apply to executables
SET_TARGET_PROPERTIES(${TargetProject}
PROPERTIES
DEBUG_POSTFIX D)
# the above applies the postfix value for executables
Additional Information:
Something like:
CMAKE_POLICY(SET CMP0021 NEW)
would enforce the new standard of allowing CMAKE_CONFIG_POSTFIX to be applied
to that configurations executables too.
==
Issue History
Date ModifiedUsername FieldChange
==
2013-07-31 14:32 Ryan H. KawickiNew Issue
==
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014328]: CMAKE_NO_BUILTIN_CHRPATH and Ninja fails
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14328 == Reported By:RolandSchulz Assigned To: == Project:CMake Issue ID: 14328 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-07-31 15:44 EDT Last Modified: 2013-07-31 15:44 EDT == Summary:CMAKE_NO_BUILTIN_CHRPATH and Ninja fails Description: Using CMAKE_NO_BUILTIN_CHRPATH together with Ninja generator fails to install with the error message: file INSTALL cannot find .../CMakeFiles/CMakeRelink.dir/libgmx.so.6. Additional Information: This is particularly annoying on OpenSuse, because they made CMAKE_NO_BUILTIN_CHRPATH default. But the error is not limited to the OpenSuse cmake binary. Setting CMAKE_NO_BUILTIN_CHRPATH also causes the problem with the binary from the cmake website. == Issue History Date ModifiedUsername FieldChange == 2013-07-31 15:44 RolandSchulz New Issue == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014329]: COMPONENT ignored when appearing after DESTINATION's
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14329 == Reported By:Andreas Pakulat Assigned To: == Project:CMake Issue ID: 14329 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-07-31 16:59 EDT Last Modified: 2013-07-31 16:59 EDT == Summary:COMPONENT ignored when appearing after DESTINATION's Description: It seems that unlike what the documentation suggests the position of the COMPONENT part of an install() command is not arbitrary. The attached project shows that the generated cmake_install.cmake file has the 'Unspecified' component set for the 'foo' target, but the expected 'applications' component set for the 'bar' target. The only difference between both is that the 'bar' target has COMPONENT before the various DESTINATION entries and 'foo' has COMPONENT after them. I tried CMake 2.8.11.2, 2.8.10 and 2.8.8 and all of them show the same incorrect (IMO) behaviour. Steps to Reproduce: 1. Run cmake on the attached minimal example 2. Inspect cmake_install.cmake and verify the components used for the 'foo' and 'bar' targets respectively == Issue History Date ModifiedUsername FieldChange == 2013-07-31 16:59 Andreas PakulatNew Issue 2013-07-31 16:59 Andreas PakulatFile Added: cmaketestcase.tar.gz == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014330]: ExternalProject download error misleading if MD5 check is used
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14330 == Reported By:RolandSchulz Assigned To: == Project:CMake Issue ID: 14330 Category: (No Category) Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2013-07-31 17:39 EDT Last Modified: 2013-07-31 17:39 EDT == Summary:ExternalProject download error misleading if MD5 check is used Description: If one uses ExternalProject with MD5 check and the download doesn't work (e.g. no internet connection), then the error message is misleading. It states that the MD5 checksum is incorrect, instead of e.g. unknown host, as it would without the MD5 check enabled. This is because the MD5 sum is checked in the file(DOWNLOAD ..) before the error code of the download is checked. Thus the wrong (/less important) error is shown. == Issue History Date ModifiedUsername FieldChange == 2013-07-31 17:39 RolandSchulz New Issue == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
