[cmake-developers] [CMake 0014751]: Generalize LINK_ONLY
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14751 == Reported By:Stephen Kelly Assigned To: == Project:CMake Issue ID: 14751 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2014-02-12 04:08 EST Last Modified: 2014-02-12 04:08 EST == Summary:Generalize LINK_ONLY Description: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9324/focus=9333 == Issue History Date ModifiedUsername FieldChange == 2014-02-12 04:08 Stephen Kelly 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] push of LinkOptionsCommand topic branch
Steve Wilson wrote: when I do the checkout followed by the reset —hard, all I get is the same set of commits that I had before. What makes you conclude they are the same? 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] AddCustomCommandWithConfig
Steve Wilson wrote: I just pushed the topic AddCustomCommandWithConfig to stage. This topic implements the CONFIG keyword for add_custom_command(). I haven't looked thoroughly, but how much does dependency specification/handling need to change? The dependency of a command on a set of targets should now be config-specific, right? Does that mean making changes to cmTargetTraceDependencies::CheckCustomCommand? What other impact is there on dependency handling here? Does the first patch in your topic pass the unit tests it adds? Is the second patch needed for that? If so, they belong in one patch, so squash them together. The documentation should be added in the patch that adds the feature, not in a separate patch. 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] AddCustomCommandWithConfig
On 02/12/2014 04:15 AM, Stephen Kelly wrote: I haven't looked thoroughly, but how much does dependency specification/handling need to change? The dependency of a command on a set of targets should now be config-specific, right? I haven't read through the topic yet but IIRC we discussed the per-config dependency problem before and concluded that we should use the union of dependencies across all configs in places where the native build tool does not support per-config dependencies. I don't recall where/when that discussion took place though. -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] Branches on next
On 2014-02-11 23:03, Ben Boeckel wrote:
On Tue, Feb 11, 2014 at 19:16:49 -0500, Matthew Woehlke wrote:
On 2014-02-11 17:54, Ben Boeckel wrote:
Parsing in CMake is split into separate sections: the part which parses
the lines into CMake's command calls and the part which expands
variables (which is why ${cmd}(${args}) isn't allowed).
Right; I'd figured that much out on my own, and my own parser AFAICT
operates in a similar manner to CMake itself... it doesn't try to
tokenize variable substitutions (I didn't need that, and it would
have made the API non-trivially more complex), although it does choke
if it seems things like '${foo\n'. From what I can tell, the CMake
command parsing pass does also?
Probably worth a test. The new parser will see:
${foo
}
and happily lookup the foo\n variable. The old parser may have choked.
Hmm... that's an interesting and perhaps undesirable behavior change.
AFAICT, the old parser, on encountering a substitution ('${', '@',
'$ENV{', '$CACHE{'), would consume '[[:alnum:]+-._/]' until it found a
matching '}' or '@'. If it found '@' or '$' it would try to consume the
substitution according to the same rules. So yes, the old parser does
reject '${foo\n}' (also '${foo~}', etc.). (Did you check that it isn't
the first stage parser that rejects these?)
As an exception to the above, spaces are allowed inside '$ENV{}' (and
maybe '$CACHE{}'?)... (Interestingly, bash won't let you set such an
environment variable... though /usr/bin/env will...)
FWIW, variables named as such can still come in through CMakeCache.txt
and probably the command line as well, so maybe there's some value here.
If it's wanted, I can tighten up the new implementation (it's also the
perfect release version to start rejecting junk like ';' or ' ' in
variable names, but it is probably too late in the release cycle at this
point).
Yeah... I have definitely wanted that (rejecting setting variables that
don't match the above rules) before :-).
I think I even mentioned that at some point as 'things I'd like to see
in 3.0'.
--
Matthew
--
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] Branches on next
On Tue, Feb 11, 2014 at 14:49:42 -0500, Ben Boeckel wrote: (though Makefiles generate faster than the configure for ParaView) and minimal for Ninja). I've addressed this…at least 2x speedup of Ninja's generate time in ParaView (2.8.12.2: 95 seconds; branch with *all* performance changes: 40 seconds; something like 55 with just the Ninja changes). It will show up on the stage in a bit. --Ben -- 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] Branches on next
On 2014-02-11 23:03, Ben Boeckel wrote: On Tue, Feb 11, 2014 at 19:16:49 -0500, Matthew Woehlke wrote: On 2014-02-11 17:54, Ben Boeckel wrote: ExpandVariablesInString is the part which takes a string which may have variables in it and dereferences them. Yes, that's why your changes are probably not all that helpful to understanding CMake's parsing... one must first understand the initial parse pass, which I assume is still in lex (unless you rewrote it too and forgot to mention it ;-), which I doubt). That code isn't even on the radar for expensive code. It probably could be replaced with smaller code other than lex/yacc, but it's not worth the time if performance is the goal (removing lines, however…). Anything other than comments and blank lines is always in the form: command ( argstring ) newline which is pretty fast (the parser is also set up once per file; the EVIS lex/yacc parser was set up and torn down for *each* expansion which is generally per-line which contains any of @$\\). Related: does the first pass then completely ignore these characters (and also genex's AFAICT?) and only perform argument splitting based on whitespace and ''? I'm wondering, since I don't try to tokenize expansions anyway, if I can just get rid of that part of my parsing without harm... -- Matthew -- 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] push of LinkOptionsCommand topic branch
I saved a copy of the branch in another of the repository. The commit numbers didn’t change and as far as I can tell they are still in the same order that I had them in when I initially pushed the branch.There are no rebases removing the downstream updates, etc... On Feb 12, 2014, at 2:08 AM, Stephen Kelly steve...@gmail.com wrote: Steve Wilson wrote: when I do the checkout followed by the reset —hard, all I get is the same set of commits that I had before. What makes you conclude they are the same? 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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] push of LinkOptionsCommand topic branch
Steve Wilson wrote: I saved a copy of the branch in another of the repository. The commit numbers didn’t change and as far as I can tell they are still in the same order that I had them in when I initially pushed the branch.There are no rebases removing the downstream updates, etc... Ah, the problem might be that your remote name is not origin, so the reset did nothing. Find the correct remote and branch. Run gitk to see it. The committer on the commits should be me. Did the reset --hard output an error message tell you what was going on? 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] AddCustomCommandWithConfig
On Feb 12, 2014, at 2:15 AM, Stephen Kelly steve...@gmail.com wrote: I haven't looked thoroughly, but how much does dependency specification/handling need to change? The dependency of a command on a set of targets should now be config-specific, right? Does that mean making changes to cmTargetTraceDependencies::CheckCustomCommand? What other impact is there on dependency handling here? I am not familiar with that code and can’t answer that question off the top of my head. Does the first patch in your topic pass the unit tests it adds? Is the second patch needed for that? If so, they belong in one patch, so squash them together. The documentation should be added in the patch that adds the feature, not in a separate patch. The first patch does pass the unit test. The second patch is not needed to pass the test, so I will not be squashing them together. I squashed the documentation into the first patch. On a side note, I am running out of time for contributing these patches back to the project. I am spending more time responding to requests to re-order and change commit messages etc.. than I am changing the code (I am learning and will get it correct one day). I understand that you want your repository history to be as correct as possible and am grateful that you care enough to try and help someone get up to speed.I need to come to some kind of compromise here. If you want these changes I am happy to contribute them, but I don’t have time to spend hours re-working things over and over. If that means it would be better to just contribute patches through email or some other format of code exchange I am happy to do that.If you would like me to just file bug/feature requests, I can do that as well. If you don’t want the changes (at least as I am able to provide them) then I can go back to maintaining my own fork of the sources. I’m not trying to complain or avoid meeting your standards, I’m just having to deal with time priorities that are not going to allow me to keep quibbling over these details. signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] Branches on next
On Wed, Feb 12, 2014 at 11:46:39 -0500, Matthew Woehlke wrote: That code isn't even on the radar for expensive code. It probably could be replaced with smaller code other than lex/yacc, but it's not worth the time if performance is the goal (removing lines, however…). Anything other than comments and blank lines is always in the form: command ( argstring ) newline which is pretty fast (the parser is also set up once per file; the EVIS lex/yacc parser was set up and torn down for *each* expansion which is generally per-line which contains any of @$\\). Related: does the first pass then completely ignore these characters (and also genex's AFAICT?) and only perform argument splitting based on whitespace and ''? I'm wondering, since I don't try to tokenize expansions anyway, if I can just get rid of that part of my parsing without harm... Also bracket'd arguments (which, IIRC, have the highest priority). Generator expressions are 100% ignored (other than not triggering errors related to the '$' being used improperly) until generate time. --Ben -- 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] AddCustomCommandWithConfig
On 02/12/2014 08:40 AM, Brad King wrote: On 02/12/2014 04:15 AM, Stephen Kelly wrote: I haven't looked thoroughly, but how much does dependency specification/handling need to change? The dependency of a command on a set of targets should now be config-specific, right? I haven't read through the topic yet but IIRC we discussed the per-config dependency problem before and concluded that we should use the union of dependencies across all configs Indeed, cmTargetTraceDependencies::CheckCustomCommand needs to be modified to consider dependencies added by per-config custom commands. This hunk: - /** Get the list of command lines. */ - const cmCustomCommandLines GetCommandLines() const; + /** Get the list of command lines for the configuration. */ + const cmCustomCommandLines +GetCommandLines(const std::string configName = ) const; should be rewritten without the default value for configName. That will expose all call sites that need to be updated, including cmTargetTraceDependencies. -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
[cmake-developers] [CMake 0014752]: Unable to run Visual Studio 2013 x64 C++ Compiler using execute_process() Command
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14752
==
Reported By:N. Thompson
Assigned To:
==
Project:CMake
Issue ID: 14752
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2014-02-12 15:19 EST
Last Modified: 2014-02-12 15:19 EST
==
Summary:Unable to run Visual Studio 2013 x64 C++ Compiler
using execute_process() Command
Description:
I have a CMakeLists.txt file that is used to build a C++ application under
Windows, Linux and Solaris. It has been used for three years and works well but
it has stopped working for Visual Studio 2013 Win64 builds.
When the project is built under Windows, we script an extra step into the
configuration phase in order to generate a list of all the h/hpp files that are
used by the project. To get the header file names, the Visual Studio C++
compiler is run using the “/Zs” option. The dynamically detected header
file names are then combined with the static cpp file names. This results in a
project that enhances the usability of the Visual Studio IDE and the SlickEdit
editor. This concept works very well for Visual Studio 2010 (x32 and X64),
Visual Studio 2012 (x32 and x64) and Visual Studio 2013 (x32 only). However,
when the CMake generator is set to “Visual Studio 12 Win64 and CMake is run,
it fails in the configuration step when it attempts to run the C++ compiler
using execute_process(). The CMake statement that runs the compiler is:
“execute_process( COMMAND ${CMAKE_CXX_COMPILER} @${response_filename}
RESULT_VARIABLE compiler_return_code OUTPUT_VARIABLE
compiler_standardoutput_stream ERROR_VARIABLE compiler_standarderror_stream)”
The error appears in a popup window when CMake is run from a Windows 7
command-line prompt. The window shows the following:
“cl.exe - Application Error The application was unable to start correctly
(0xc07b). Click OK to close the application.”
Some reports on the web suggest that sometimes these errors are caused by the
improper use of 32bit/64 bit DLLs.
Steps to Reproduce:
The CMakeLists.txt file is complex. Currently trying to strip it down to a
portable example that demonstrates the failure.
==
Issue History
Date ModifiedUsername FieldChange
==
2014-02-12 15:19 N. ThompsonNew 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] Branches on next
On Wed, Feb 12, 2014 at 11:42:53 -0500, Ben Boeckel wrote:
I've addressed this…at least 2x speedup of Ninja's generate time in
ParaView (2.8.12.2: 95 seconds; branch with *all* performance changes:
40 seconds; something like 55 with just the Ninja changes). It will show
up on the stage in a bit.
This has been pushed; the custom-parsers branch has been reverted due to
many corner cases still existing (interactions between @ and ${}
expansion and it being to lax in literal characters allowed in variable
names).
--Ben
--
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] [New Module] FindOpenCL, FindHg
Hi Eike, all right, then Hg, as it's FindHg, unless there is a naming policy I'm not aware of. I was just confused a bit due to FindGit, which uses GIT_ as the prefix. How do I proceed from here? What should I do next? Cheers, Matthäus On 08.02.2014 17:38, Rolf Eike Beer wrote: Am Samstag, 8. Februar 2014, 16:38:02 schrieb Matthäus G. Chajdas: Hi Eike, thanks for taking a look. I've changed the module accordingly. Is there a recommendation whether to use HG_ or Hg_ as the prefix for the variables? As I guess there will be a bit back forth here, I've also pushed them to a repository on github: https://github.com/Anteru/findhgcl That's simple: the same way as the module is called. CMake set's some automatic variables, e.g. to reflect the REQUIRED and version arguments given to the find_package() call. These are set the same way as the module name is spelled, and so does FPHSA. Eike -- 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] Adding custom namespaces to FindBoost
Given the complicated nature of FindBoost and it's many many use cases, I'd
like to run this by the list for inclusion in to the FindBoost.cmake
module. First let me preface this with the note that this patch maintains
100% backwards compatibility and will default to the current behaviour.
That being said, here's the patch.
Justification:
Often when using a private copy of boost you'll want to extract a small
subset and build it with a custom namespace instead of boost::. This
generally involves a different name for the libraries as well. This is
usually to remove any symbol conflicts either with external dependencies
also built with boost or with being used as a dependency in something else
that needs it's own version of boost. Luckiliy, the boost distribution
contains a tool, bcp, to do all of this for you. It will extract a subset
of boost, change it's namespace to one you specify, and rename the
libraries it builds accordingly.
Patch description:
The FindBoost module currently assumes all boost libraries will be named
boost_foo and currently will not find these renamed libraries. This patch
ds a Boost_NAMESPACE option to allo myboost_foo to be found instead.
Patch attached
- Chuck
From cfc0008206155c5244c205c3f77bba911c109b6c Mon Sep 17 00:00:00 2001
From: Chuck Atkins chuck.atk...@kitware.com
Date: Wed, 12 Feb 2014 15:33:46 -0500
Subject: [PATCH] Add suport for custom namespaces in FindBoost.
This patch defaults to existing behavior and does NOT break backwards
compatibility. When building boost with an alternate namespace the libraries
generated will have a different naming convention. This is often done to
ensure no symbol conflicts with external libries built against a different
version of boost. If the namespace used is myprivateboost:: instad of
boost:: then the libraries built will be myprivateboost_foo instead of
boost_foo. This patch add an option to specify a custom namespace used to
alter the library names that get searched for.
---
Modules/FindBoost.cmake | 62 +
1 file changed, 37 insertions(+), 25 deletions(-)
diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 945694d..a57e12c 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -99,6 +99,9 @@
# Boost_THREADAPI - Suffix for thread component library name,
# such as pthread or win32. Names with
# and without this suffix will both be tried.
+# Boost_NAMESPACE - Alternate namespace used to build boost with
+# e.g. if set to myboost, will search for
+# myboost_thread instead of boost_thread.
#
# Other variables one may set to control this module are::
#
@@ -736,10 +739,24 @@ else()
endif()
#
+# Prefix initialization
+#
+
+set(Boost_LIB_PREFIX )
+if ( WIN32 AND Boost_USE_STATIC_LIBS AND NOT CYGWIN)
+ set(Boost_LIB_PREFIX lib)
+endif()
+
+if ( NOT Boost_NAMESPACE )
+ set(Boost_NAMESPACE boost)
+endif()
+
+#
# Suffix initialization and compiler suffix detection.
#
set(_Boost_VARS_NAME
+ Boost_NAMESPACE
Boost_COMPILER
Boost_THREADAPI
Boost_USE_DEBUG_PYTHON
@@ -752,11 +769,6 @@ set(_Boost_VARS_NAME
_Boost_CHANGE_DETECT(_Boost_CHANGE_LIBNAME ${_Boost_VARS_NAME})
# Setting some more suffixes for the library
-set(Boost_LIB_PREFIX )
-if ( WIN32 AND Boost_USE_STATIC_LIBS AND NOT CYGWIN)
- set(Boost_LIB_PREFIX lib)
-endif()
-
if (Boost_COMPILER)
set(_boost_COMPILER ${Boost_COMPILER})
if(Boost_DEBUG)
@@ -966,18 +978,18 @@ foreach(COMPONENT ${Boost_FIND_COMPONENTS})
# Find RELEASE libraries
#
set(_boost_RELEASE_NAMES
-${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}-${Boost_LIB_VERSION}
-${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}
-${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}-${Boost_LIB_VERSION}
-${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}
-${Boost_LIB_PREFIX}boost_${COMPONENT} )
+${Boost_LIB_PREFIX}${Boost_NAMESPACE}_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}-${Boost_LIB_VERSION}
+${Boost_LIB_PREFIX}${Boost_NAMESPACE}_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}
+${Boost_LIB_PREFIX}${Boost_NAMESPACE}_${COMPONENT}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}-${Boost_LIB_VERSION}
+${Boost_LIB_PREFIX}${Boost_NAMESPACE}_${COMPONENT}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}
+
Re: [cmake-developers] Branches on next
On Tue, Feb 11, 2014 at 19:16:49 -0500, Matthew Woehlke wrote:
If you're looking for corner-cases, check out the RunCMake.Syntax test
in the source tree. If you can handle that, you're probably doing pretty
well on the basics.
Thanks; I may do that some time.
Also look at RunCMake.variable_expansion (on next).
Speaking of corner cases, one evil case I thought up of is not as evil
as it could have been:
set(0 TRUE)
if (0)
message(madness)
else ()
message(actually called)
endif ()
This is however, is slightly evil:
set(zero 00)
if (zero)
message(actually called)
else ()
message(well, it was a nice thought)
endif ()
if (${zero})
message(wait a minute...)
else ()
message(actually called)
endif ()
Not sure how if want to handle that with a policy or not.
--Ben
--
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 0014753]: Place CMAKE_CXX_FLAGS_DEBUG before CMAKE_CXX_FLAGS, not after (for all similar flags)
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14753
==
Reported By:Dmiry Marakasov
Assigned To:
==
Project:CMake
Issue ID: 14753
Category: CMake
Reproducibility:always
Severity: tweak
Priority: normal
Status: new
==
Date Submitted: 2014-02-12 20:08 EST
Last Modified: 2014-02-12 20:08 EST
==
Summary:Place CMAKE_CXX_FLAGS_DEBUG before CMAKE_CXX_FLAGS,
not after (for all similar flags)
Description:
The example below goes to CMAKE_CXX_FLAGS_DEBUG, however the report covers all
flags which have CMAKE_BUILD_TYPE-dependent counterparts (e.g.
CMAKE_{C,CXX,LINK,...}_FLAGS_*)
Currently, CMAKE_CXX_FLAGS_DEBUG goes to compiler flags after CMAKE_CXX_FLAGS.
This is inconvenient, as it does not allow user to override project-set flags
with flags suitable for local environment. For example, FreeBSD ports collection
has a policy of enforcing systemwide optimization (-Ox) flags on all port
builds. These flags are passed via CMAKE_CC_FLAGS/CMAKE_CXX_FLAGS, but when
BUILD_TYPE is used (it is) they do not override project-set flags, which is
undesirable. The only ways to fix this are either to not use CMAKE_BUILD_TYPE
(which is not acceptable as build-type specific flags may contain critical
features, e.g. -DNDEBUG which may severely affect performance and program
bahavior) or patch CMakeLists.txt to remove unwanted vendor's flags (not very
nice either).
Placing CMAKE_*_FLAGS _after_ CMAKE_*_FLAGS_* will allow gracefully overriding
of needed flags so that is what I propose.
==
Issue History
Date ModifiedUsername FieldChange
==
2014-02-12 20:08 Dmiry MarakasovNew 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
