[cmake-developers] [CMake 0012449]: CPack.cmake wrong CPACK_INSTALLED_DIRECTORIES docs, caused wrong docs at Wiki/CMake:CPackConfiguration#Advanced_settings
The following issue has been SUBMITTED. == http://www.itk.org/Bug/view.php?id=12449 == Reported By:Andreas Mohr Assigned To: == Project:CMake Issue ID: 12449 Category: Documentation Reproducibility:always Severity: major Priority: urgent Status: new == Date Submitted: 2011-09-08 11:34 EDT Last Modified: 2011-09-08 11:34 EDT == Summary:CPack.cmake wrong CPACK_INSTALLED_DIRECTORIES docs, caused wrong docs at Wiki/CMake:CPackConfiguration#Advanced_settings Description: git CPack.cmake wrongly lists CPACK_INSTALL_DIRECTORIES, which probably caused http://www.cmake.org/Wiki/CMake:CPackConfiguration#Advanced_settings to (originally) adopt the same invalid spelling (should be CPACK_INSTALLED_DIRECTORIES). Source handling always does seem to reference the INSTALL*ED* setting. Priority urgent since it's an almost-unforgivable documentation mistake which rippled through several places and can be fixed easily. And severity major since users adopting that misspelt variable likely leaves them without any directories installed. Thanks! == Issue History Date ModifiedUsername FieldChange == 2011-09-08 11:34 Andreas Mohr New Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Indrect function calls
There are already these feature requests that seem to cover the exact same topic: http://public.kitware.com/Bug/view.php?id=11845 http://public.kitware.com/Bug/view.php?id=4034 Yes, the second ticket has the same idea, but, as I can see, it was completely rejected. I personally do not think that creating include file for a single function is a suitable workaround. I personally do not think that EVAL adds significant value to the CMake language. And I think it would introduce vastly more complexity/confusion than it could possibly be worth. But that's just my own personal 2 cents. As for me, I don't think so. It will add extra flexibility by cost of nothing. Writing complex/confusing code is easy in any language regardless the presence of 'eval' or macro names expansion in it. Use tcl if you want eval. Sounds like See figure 1. Also, eval functionality isn't TCL specific, it can be found in many languages from perl to javascript. Thank you for your answers, guys. Firegurafiku ___ 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] novice question: modification of FLAGS rule variable?
The set_target_properties() of COMPILE_FLAGS allows you to add the -DDEBUG
just for the mylibd target (although you should really use the
COMPILE_DEFINITIONS property for preprocessor symbols). Why do you need to
mess with the FLAGS part of the compile command ? Can't you add extra
compiler command flags like this:
set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -myFlag)
or even replace the default flags entirely like this:
set(CMAKE_C_FLAGS -foo)
I'm not sure what you are trying to achieve. Can you explain in a bit more
detail ?
--
Glenn
On 8 September 2011 04:35, David Dunkle ddun...@arxan.com wrote:
Thanks, Glenn. That almost works. However, the values of FLAGS is hard to
construct in this case. It looks something like this:
** **
add_library(mylib, STATIC, ${files})
set_target_properties(mylib
PROPERTIES PREFIX “”
COMPILE_FLAGS
${target_compiler_flags})
add_library(mylibd, STATIC, ${files})
set_target_properties(mylibd,
PROPERTIES PREFIX “”
COMPILE_FLAGS “-DDEBUG
${target_compiler_flags}”)
…
set(CMAKE_C_COMPILE_OBJECT ${target_compiler} -c FLAGS -o OBJECT)***
*
** **
I can replace FLAGS with ${target_compiler_flags} yielding this:
** **
set(CMAKE_C_COMPILE_OBJECT “${target_compiler} –c ${target_compiler_flags}
–o OBJECT”)
** **
but then the –DDEBUG is missing for the build of mylibd. I guess both
mylibd and mylib use CMAKE_C_COMPILE_OBJECT and I need a way to pass the
–DDEBUG to the compile of one and not the other.
** **
-David
** **
*From:* Glenn Coombs [mailto:glenn.coo...@gmail.com]
*Sent:* Wednesday, September 07, 2011 4:19 AM
*To:* David Cole
*Cc:* David Dunkle; cmake@cmake.org
*Subject:* Re: [CMake] novice question: modification of FLAGS rule
variable?
** **
What you can do however is set the variable which uses the FLAGS
definition, i.e. CMAKE_C_COMPILE_OBJECT in your example. I have a
CMakeLists.txt file where I override the default assembler flags:
set(CMAKE_ASM-ATT_COMPILE_OBJECT CMAKE_ASM-ATT_COMPILER ${ASM_SYS_FLAGS}
-o OBJECT SOURCE)
to use what is set in my ASM_SYS_FLAGS variable instead of the default
FLAGS one. I'm not sure but I think you are supposed to set these sort of
variables early on in a CMakeList.txt before the project() or
enable_language() commands. Also, I think that later changes to the
ASM_SYS_FLAGS variable are ignored.
--
Glenn
On 5 September 2011 19:53, David Cole david.c...@kitware.com wrote:
On Mon, Sep 5, 2011 at 1:31 PM, David Dunkle ddun...@arxan.com wrote:
Is it possible to read and to set a property/rule variable like FLAGS?
What syntax would I use to do that? I mean FLAGS as it, for example,
appears here:
set(CMAKE_C_COMPILE_OBJECT ${target_compiler} -c FLAGS -o OBJECT)
For example can I do something like this (this is pseudo code)?
#read
set(MY_FLAGS, ${FLAGS} );
…
#set
set(FLAGS, ${MY_FLAGS});
In the documentation, here:
http://cmake.org/Wiki/CMake_Useful_Variables#Expansion_Rules
it hints at this being possible but doesn’t explain, at least not so that
I
understand.
Thanks,
-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
The wiki page is simply misleading. You cannot set those from the
CMake language. CMake decides on their values in internal code, and
then substitutes appropriately when generating make files or
solution/project files for the build system.
You can set things the CMAKE_CXX_FLAGS which eventually get
translated into the substitution that CMake performs, but you cannot
alter FLAGS in the rules variables.
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
** **
___
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
[CMake] How to executing a script right after an add_test command ?
Hi all,
I am using the Qt module QTestLib to do some tests on my application
(windows, MSVC 2008) that has been all set up with CMake.
A test I have created with QTestLib is executed, all output is sent to the
command window. Since I want it to a file, I used what Qt suggest to
redirect all output: -xml -o my_file.xml
so I do this in my CMake file:
add_test ( NAME ${PROJECT_NAME} COMMAND ${PROJECT_NAME} -xml -o
log/foo.xml )
So now, when I do the run_test through visual, my test is run and my file
is created (so far so good!).
My problem is that I want the name of the file to be time and date dependant
(log20110908140230.xml - a year, month, day, hour, minute and second
format).
So I have considered the following solution (I did not succeed in
implementing it so far):
I want to execute a script, just after the execution of my test that will
rename the result file generated.
-- Here I don't know how I can tell CMake to execute my script just when
the test has been executed ?
NB: I do NOT have any problem creating a script that rename a foo.xml file
to a log20110908140230.xml file (my script.bat file is already ready). The
problem is how to make this script to be executed just after the test
execution.
Any insight is welcomed on how to implement my suggestion (or if you have
another choice, I'm all ears :)! ).
___
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] How to executing a script right after an add_test command ?
On Thu, Sep 8, 2011 at 9:30 AM, Delphinus Delphinus
tibourox...@yahoo.fr wrote:
Hi all,
I am using the Qt module QTestLib to do some tests on my application
(windows, MSVC 2008) that has been all set up with CMake.
A test I have created with QTestLib is executed, all output is sent to the
command window. Since I want it to a file, I used what Qt suggest to
redirect all output: -xml -o my_file.xml
so I do this in my CMake file:
add_test ( NAME ${PROJECT_NAME} COMMAND ${PROJECT_NAME} -xml -o
log/foo.xml )
So now, when I do the run_test through visual, my test is run and my file
is created (so far so good!).
My problem is that I want the name of the file to be time and date dependant
(log20110908140230.xml - a year, month, day, hour, minute and second
format).
So I have considered the following solution (I did not succeed in
implementing it so far):
I want to execute a script, just after the execution of my test that will
rename the result file generated.
-- Here I don't know how I can tell CMake to execute my script just when
the test has been executed ?
NB: I do NOT have any problem creating a script that rename a foo.xml file
to a log20110908140230.xml file (my script.bat file is already ready). The
problem is how to make this script to be executed just after the test
execution.
Any insight is welcomed on how to implement my suggestion (or if you have
another choice, I'm all ears :)! ).
___
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
You can either:
(1) execute your script as an additional test that depends on the
first one (so that guarantees it to run *after* the test, even in
parallel testing scenarios, although not necessarily *immediately*
after)
or
(2) execute a single script as the test itself, and then inside that
script, execute the real test first, followed immediately by the
script your already have...
I would do option #2 if I were you. :-)
You can probably find other examples of this by googling around for
add_test script cmake ( one of the hits is another reply I made
previously on this list:
http://www.cmake.org/pipermail/cmake/2011-May/044180.html )
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] Bug #12189
The reason I didn't check _SBCS is that I introduced that as a control
to CMake. _MBCS and _UNICODE are defined by the compiler based on the
CharacterSet setting. The test is being executed inside an
IF(${CMAKE_TEST_GENERATOR} MATCHES Visual Studio). Is that
insufficient to guarantee it only runs with VS?
Aaron Meadows
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Meadows, Aaron C.
Sent: Tuesday, September 06, 2011 3:18 PM
To: David Cole
Cc: cmake@cmake.org
Subject: Re: [CMake] Bug #12189
Sounds good. I believe the test is already in an msvc block. The other
is easily added. I'll get on it tomorrow.
Any thoughts on where to document it?
Sent from my iPhone
On Sep 6, 2011, at 3:15 PM, David Cole david.c...@kitware.com wrote:
Thanks for your work on this Aaron. It looks almost good enough to
merge as is -- so close! Just two more things: I want to make sure the
test is conditional on MSVC (unless your intent is to make this work
everywhere?) and tweak the test slightly: I think it should also
verify that _SBCS is defined in addition to checking _UNICODE and
_MBCS.
Unfortunately, I'm running out of time to apply patches, make sure
they work on all platforms, and then get the merged in for the
upcoming 2.8.6 release.
I'll try to get to this one soon after the 2.8.6 release so that it
will be included in the next release.
Thanks,
David
On Thu, Sep 1, 2011 at 11:29 AM, aaron.mead...@thomsonreuters.com
wrote:
Hi David,
I've updated the bug with a patch which adds a test to check that
defining _SBCS does set CharacterSet to 0 (Single Byte Character Set).
I checked that it works when _SBCS is set and fails when _SBCS is not
defined.
I looked for where the _UNICODE option is documented, thinking to
document _SBCS there, but was unable to find it in the documentation.
If you want to point me to the right location to add documentation,
I'm happy to write some. (I can write some for _UNICODE as well, if
you like.)
Aaron Meadows
-Original Message-
From: David Cole [mailto:david.c...@kitware.com]
Sent: Wednesday, August 31, 2011 1:04 PM
To: Meadows, Aaron C.
Cc: cmake@cmake.org
Subject: Re: [CMake] Bug #12189
The CMake/Tests/CMakeLists.txt file lists most of the tests that
execute on our dashboards.
The directories under CMake/Tests are all the existing test source
trees. If you want to modify one of the existing tests to have an
_SBCS target compile definition, I'd start by looking at Simple or
COnly as a simple basis for a new test.
Or you may find another one where the code that's compiled and tested
is compatible with _SBCS.
You may want to conditionalize it with code like:
if (CMAKE_GENERATOR MATCHES Visual Studio) or
if (MSVC)
since your changes only apply to the Visual Studio generators. It
should work with cl and nmake too, though, to have an _SBCS
definition. Other compilers may or may not like a -D_SBCS.
Let me know if you need further guidance.
Thanks,
David
On Wed, Aug 31, 2011 at 1:33 PM, aaron.mead...@thomsonreuters.com
wrote:
I'm happy to assist in any way I can. Where do I need to add a
test? Also, where would it be appropriate to document this?
Aaron Meadows
-Original Message-
From: David Cole [mailto:david.c...@kitware.com]
Sent: Wednesday, August 31, 2011 11:02 AM
To: Meadows, Aaron C.
Cc: cmake@cmake.org
Subject: Re: [CMake] Bug #12189
Your patch has the wrong sense I think It looks like it's
removing _SBCS code, but you want to add all that code, correct?
I think (as long as my above assumption is correct) that this patch
should be ok, even in a backwards compatibility sense, because only
people who have _SBCS defined as a target property compile definition
will have code generated differently than before.
And I suspect your the only person in the world at this point for
whom this is true. :-)
Of course, to accept it into CMake, it would be nice to have it
documented somewhere, and to have a test that exercises the newly added
code. Especially now that we've entered the release candidate phase of
2.8.6.
Any chance you can add a test (or modify an existing one) to add the
_SBCS compile definition as a target property?
On Wed, Aug 31, 2011 at 11:38 AM,
aaron.mead...@thomsonreuters.com wrote:
Any of you CMakers want to comment on this bug and patch? I'd like
to be able to switch my company back to the public version of CMake
instead of compiling my own flavor every time there is a release...
Aaron Meadows
From: Meadows, Aaron C.
Sent: Thursday, June 23, 2011 2:23 PM
To: Meadows, Aaron C.; 'cmake@cmake.org'
Subject: RE: [CMake] Bug #12189
I've updated the bug with an additional patch (had a bug for some
configuration cases).
What is the procedure to get this patch considered and applied? Do
I need to contact the Visual Studio
Re: [CMake] How to executing a script right after an add_test command ?
On Thu, Sep 8, 2011 at 3:39 PM, David Cole david.c...@kitware.com wrote:
On Thu, Sep 8, 2011 at 9:30 AM, Delphinus Delphinus wrote:
Hi all,
I am using the Qt module QTestLib to do some tests on my application
(windows, MSVC 2008) that has been all set up with CMake.
A test I have created with QTestLib is executed, all output is sent to
the
command window. Since I want it to a file, I used what Qt suggest to
redirect all output: -xml -o my_file.xml
so I do this in my CMake file:
add_test ( NAME ${PROJECT_NAME} COMMAND ${PROJECT_NAME} -xml -o
log/foo.xml )
So now, when I do the run_test through visual, my test is run and my
file
is created (so far so good!).
My problem is that I want the name of the file to be time and date
dependant
(log20110908140230.xml - a year, month, day, hour, minute and second
format).
So I have considered the following solution (I did not succeed in
implementing it so far):
I want to execute a script, just after the execution of my test that will
rename the result file generated.
-- Here I don't know how I can tell CMake to execute my script just when
the test has been executed ?
NB: I do NOT have any problem creating a script that rename a foo.xml
file
to a log20110908140230.xml file (my script.bat file is already ready).
The
problem is how to make this script to be executed just after the test
execution.
Any insight is welcomed on how to implement my suggestion (or if you have
another choice, I'm all ears :)! ).
You can either:
(1) execute your script as an additional test that depends on the
first one (so that guarantees it to run *after* the test, even in
parallel testing scenarios, although not necessarily *immediately*
after)
or
(2) execute a single script as the test itself, and then inside that
script, execute the real test first, followed immediately by the
script your already have...
I would do option #2 if I were you. :-)
You can probably find other examples of this by googling around for
add_test script cmake ( one of the hits is another reply I made
previously on this list:
http://www.cmake.org/pipermail/cmake/2011-May/044180.html )
HTH,
David
Thanks. And yes, it helped !
I chose option #2.
I created a runAndRename.cmake file:
macro(COMMAND_EXEC1 P_COMMAND)
execute_process(COMMAND ${P_COMMAND} -xml -o log/foo.xml RESULT_VARIABLE
RESULT_VAR_COMMAND)
if(RESULT_VAR_COMMAND)
message(FATAL_ERROR Error ${P_COMMAND})
endif()
endmacro()
macro(COMMAND_EXEC2 P_COMMAND)
execute_process(COMMAND ${P_COMMAND} WORKING_DIRECTORY
${CMAKE_CURRENT_SOURCE_DIR} RESULT_VARIABLE RESULT_VAR_COMMAND)
if(RESULT_VAR_COMMAND)
message(FATAL_ERROR Error ${P_COMMAND})
endif()
endmacro()
COMMAND_EXEC1(${COMMAND1})
COMMAND_EXEC2(${COMMAND2})
And then in my CMakeLists.txt, I have now:
add_test( NAME ${PROJECT_NAME} COMMAND ${CMAKE_COMMAND}
-DCOMMAND1=$TARGET_FILE:${PROJECT_NAME}
-DCOMMAND2=renameExe
-P
${CMAKE_CURRENT_SOURCE_DIR}/runAndRename.cmake)
It is working for me, even though there is still a lot of room for
improvement:
- I did not find the proper way to pass the needed arguments (-xml -o
filename) ... so I created two macros :(.
- And I spent most of my time figuring out that I should transform
myScript.BAT to a myScript.EXE to make my second part work !
I'll look into those later...
___
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] novice question: modification of FLAGS rule variable?
I inherited this cmake build that builds a complex project with a fairly large
directory tree. Part way through it switches compilers, with code similar to
what is below, and builds a few subdirectories using the new compilers. The
compiler flags for the original compilers (compiler A) bleeds through to the
new compilers (compiler B), because of the FLAGS below. The code below is in
the CMakeLists.txt of the subdirectory that switches to the new compiler.
Now I need to build on a new platform, which involves adding only one new
compiler flag (-m32) to compiler A. Unfortunately, the -m32 is picked up by the
FLAGS below and passed to compiler B, which does not support this flag, and
gives an error.
So, I am trying to figure out if I can modify the existing code to remove the
-m32 from FLAGS for compiler B, or if I need to basically rewrite the
compiler B part of the build so that the subdirectories using compiler B are a
separate cmake project. The rewrite idea is hard to justify in schedule sense
to remove one flag, and I have to be sure it's necessary.
While conceptually removing one -m32 flag seems simple, I am having a very hard
time figuring out how to do it in cmake. Removing the single flag from compiler
B can take two forms, as we have discussed. I can obtain the existing flags and
remove the -m32 or I can substitute the new flags completely.
The removal option has not worked so far, possibly because this removal is
occurring in a subdirectory of the original long after the project is
established, and possibly because I am not sure which variable to modify. The
CMAKE_C_FLAGS is already modified in this case, to no effect on FLAGS,
possibly because its occurring long after the project is established. Can I
get_target_property on COMPILER_FLAGS and modify that?
The second option almost works, but I can't figure out how to obtain the
-DDEBUG option that is currently established with set_target_properties, as
described below.
-David
From: Glenn Coombs [mailto:glenn.coo...@gmail.com]
Sent: Thursday, September 08, 2011 3:15 AM
To: David Dunkle
Cc: David Cole; cmake@cmake.org
Subject: Re: [CMake] novice question: modification of FLAGS rule variable?
The set_target_properties() of COMPILE_FLAGS allows you to add the -DDEBUG just
for the mylibd target (although you should really use the COMPILE_DEFINITIONS
property for preprocessor symbols). Why do you need to mess with the FLAGS
part of the compile command ? Can't you add extra compiler command flags like
this:
set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -myFlag)
or even replace the default flags entirely like this:
set(CMAKE_C_FLAGS -foo)
I'm not sure what you are trying to achieve. Can you explain in a bit more
detail ?
--
Glenn
On 8 September 2011 04:35, David Dunkle
ddun...@arxan.commailto:ddun...@arxan.com wrote:
Thanks, Glenn. That almost works. However, the values of FLAGS is hard to
construct in this case. It looks something like this:
add_library(mylib, STATIC, ${files})
set_target_properties(mylib
PROPERTIES PREFIX
COMPILE_FLAGS ${target_compiler_flags})
add_library(mylibd, STATIC, ${files})
set_target_properties(mylibd,
PROPERTIES PREFIX
COMPILE_FLAGS -DDEBUG
${target_compiler_flags})
...
set(CMAKE_C_COMPILE_OBJECT ${target_compiler} -c FLAGS -o OBJECT)
I can replace FLAGS with ${target_compiler_flags} yielding this:
set(CMAKE_C_COMPILE_OBJECT ${target_compiler} -c ${target_compiler_flags} -o
OBJECT)
but then the -DDEBUG is missing for the build of mylibd. I guess both mylibd
and mylib use CMAKE_C_COMPILE_OBJECT and I need a way to pass the -DDEBUG to
the compile of one and not the other.
-David
From: Glenn Coombs
[mailto:glenn.coo...@gmail.commailto:glenn.coo...@gmail.com]
Sent: Wednesday, September 07, 2011 4:19 AM
To: David Cole
Cc: David Dunkle; cmake@cmake.orgmailto:cmake@cmake.org
Subject: Re: [CMake] novice question: modification of FLAGS rule variable?
What you can do however is set the variable which uses the FLAGS definition,
i.e. CMAKE_C_COMPILE_OBJECT in your example. I have a CMakeLists.txt file
where I override the default assembler flags:
set(CMAKE_ASM-ATT_COMPILE_OBJECT CMAKE_ASM-ATT_COMPILER ${ASM_SYS_FLAGS} -o
OBJECT SOURCE)
to use what is set in my ASM_SYS_FLAGS variable instead of the default FLAGS
one. I'm not sure but I think you are supposed to set these sort of variables
early on in a CMakeList.txt before the project() or enable_language() commands.
Also, I think that later changes to the ASM_SYS_FLAGS variable are ignored.
--
Glenn
On 5 September 2011 19:53, David Cole
david.c...@kitware.commailto:david.c...@kitware.com wrote:
On Mon, Sep 5, 2011 at 1:31 PM, David Dunkle
ddun...@arxan.commailto:ddun...@arxan.com wrote:
Is it possible to read and to set a property/rule variable like FLAGS?
What
Re: [CMake] novice question: modification of FLAGS rule variable?
Is the -m32 flag being provided as a default by cmake, or are you specifying
it yourself ? If the latter, then maybe it has been added to the
COMPILE_DEFINITIONS property instead of the CMAKE_C_FLAGS variable. I have
seen CMakeList.txt files use add_definitions(-m32) rather than adding it to
the CMAKE_C_FLAGS variable. That would explain why explicitly setting
CMAKE_C_FLAGS wasn't removing it. Also, is it C files or C++ files that are
being compiled, because C++ files use CMAKE_CXX_FLAGS instead of
CMAKE_C_FLAGS.
On 8 September 2011 18:16, David Dunkle ddun...@arxan.com wrote:
I inherited this cmake build that builds a complex project with a fairly
large directory tree. Part way through it switches compilers, with code
similar to what is below, and builds a few subdirectories using the new
compilers. The compiler flags for the original compilers (compiler A) bleeds
through to the new compilers (compiler B), because of the FLAGS below. The
code below is in the CMakeLists.txt of the subdirectory that switches to the
new compiler.
** **
Now I need to build on a new platform, which involves adding only one new
compiler flag (-m32) to compiler A. Unfortunately, the –m32 is picked up by
the FLAGS below and passed to compiler B, which does not support this
flag, and gives an error.
** **
So, I am trying to figure out if I can modify the existing code to remove
the –m32 from FLAGS for compiler B, or if I need to basically rewrite the
compiler B part of the build so that the subdirectories using compiler B are
a separate cmake project. The rewrite idea is hard to justify in schedule
sense to remove one flag, and I have to be sure it’s necessary.
** **
While conceptually removing one –m32 flag seems simple, I am having a very
hard time figuring out how to do it in cmake. Removing the single flag from
compiler B can take two forms, as we have discussed. I can obtain the
existing flags and remove the –m32 or I can substitute the new flags
completely.
** **
The removal option has not worked so far, possibly because this removal is
occurring in a subdirectory of the original long after the project is
established, and possibly because I am not sure which variable to modify.
The CMAKE_C_FLAGS is already modified in this case, to no effect on FLAGS,
possibly because its occurring long after the project is established. Can I
get_target_property on COMPILER_FLAGS and modify that?
** **
The second option almost works, but I can’t figure out how to obtain the
–DDEBUG option that is currently established with set_target_properties, as
described below.
** **
-David
** **
*From:* Glenn Coombs [mailto:glenn.coo...@gmail.com]
*Sent:* Thursday, September 08, 2011 3:15 AM
*To:* David Dunkle
*Cc:* David Cole; cmake@cmake.org
*Subject:* Re: [CMake] novice question: modification of FLAGS rule
variable?
** **
The set_target_properties() of COMPILE_FLAGS allows you to add the -DDEBUG
just for the mylibd target (although you should really use the
COMPILE_DEFINITIONS property for preprocessor symbols). Why do you need to
mess with the FLAGS part of the compile command ? Can't you add extra
compiler command flags like this:
set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -myFlag)
or even replace the default flags entirely like this:
set(CMAKE_C_FLAGS -foo)
I'm not sure what you are trying to achieve. Can you explain in a bit more
detail ?
--
Glenn
On 8 September 2011 04:35, David Dunkle ddun...@arxan.com wrote:
Thanks, Glenn. That almost works. However, the values of FLAGS is hard to
construct in this case. It looks something like this:
add_library(mylib, STATIC, ${files})
set_target_properties(mylib
PROPERTIES PREFIX “”
COMPILE_FLAGS
${target_compiler_flags})
add_library(mylibd, STATIC, ${files})
set_target_properties(mylibd,
PROPERTIES PREFIX “”
COMPILE_FLAGS “-DDEBUG
${target_compiler_flags}”)
…
set(CMAKE_C_COMPILE_OBJECT ${target_compiler} -c FLAGS -o OBJECT)***
*
I can replace FLAGS with ${target_compiler_flags} yielding this:
set(CMAKE_C_COMPILE_OBJECT “${target_compiler} –c ${target_compiler_flags}
–o OBJECT”)
but then the –DDEBUG is missing for the build of mylibd. I guess both
mylibd and mylib use CMAKE_C_COMPILE_OBJECT and I need a way to pass the
–DDEBUG to the compile of one and not the other.
-David
*From:* Glenn Coombs [mailto:glenn.coo...@gmail.com]
*Sent:* Wednesday, September 07, 2011 4:19 AM
*To:* David Cole
*Cc:* David Dunkle; cmake@cmake.org
*Subject:* Re: [CMake] novice question: modification of FLAGS rule
variable?
What you can do however is set the variable which uses the FLAGS
Re: [CMake] Bug #12189
On Thu, Sep 8, 2011 at 11:17 AM, aaron.mead...@thomsonreuters.com wrote:
The reason I didn't check _SBCS is that I introduced that as a control
to CMake. _MBCS and _UNICODE are defined by the compiler based on the
CharacterSet setting.
OK, but since you're using it as a target level #define, it should be
defined in the test, right? So code something like:
#ifndef _SBCS
#error _SBCS should be defined
#endif
...would be ok to have, too. The rest of the code verifies that
neither _UNICODE nor _MBCS is defined, but waits until runtime to
cause a failure.
An alternate approach (what I would do, since it fails earlier, at
compile time) would be:
#ifdef _UNICODE
#error _UNICODE should not be defined
#endif
#ifdef _MBCS
#error _MBCS should not be defined
#endif
// If it compiles and runs, it succeeds:
return 0;
The test is being executed inside an
IF(${CMAKE_TEST_GENERATOR} MATCHES Visual Studio). Is that
insufficient to guarantee it only runs with VS?
Nope. That's sufficient. I simply failed to notice the IF... My bad.
However, the other tests in that block all start with VS in the
name. If the test is only going to run for VS generators, (and not the
NMake Makefiles generator), then we should name it with a leading VS.
One more note: are you using git -- if so, simply make this as a
commit on top of the existing CMake 'master' branch (any commit that's
contained in 'master'), and then do:
$ git format-patch -1
And attach *that* patch. That will preserve your authorship
information in the patch file, and makes it a snap for us to apply
with '$ git am -3 0001-your-commit.patch' on our end.
Cheers (and thanks again),
David
Aaron Meadows
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Meadows, Aaron C.
Sent: Tuesday, September 06, 2011 3:18 PM
To: David Cole
Cc: cmake@cmake.org
Subject: Re: [CMake] Bug #12189
Sounds good. I believe the test is already in an msvc block. The other
is easily added. I'll get on it tomorrow.
Any thoughts on where to document it?
Sent from my iPhone
On Sep 6, 2011, at 3:15 PM, David Cole david.c...@kitware.com wrote:
Thanks for your work on this Aaron. It looks almost good enough to
merge as is -- so close! Just two more things: I want to make sure the
test is conditional on MSVC (unless your intent is to make this work
everywhere?) and tweak the test slightly: I think it should also
verify that _SBCS is defined in addition to checking _UNICODE and
_MBCS.
Unfortunately, I'm running out of time to apply patches, make sure
they work on all platforms, and then get the merged in for the
upcoming 2.8.6 release.
I'll try to get to this one soon after the 2.8.6 release so that it
will be included in the next release.
Thanks,
David
On Thu, Sep 1, 2011 at 11:29 AM, aaron.mead...@thomsonreuters.com
wrote:
Hi David,
I've updated the bug with a patch which adds a test to check that
defining _SBCS does set CharacterSet to 0 (Single Byte Character Set).
I checked that it works when _SBCS is set and fails when _SBCS is not
defined.
I looked for where the _UNICODE option is documented, thinking to
document _SBCS there, but was unable to find it in the documentation.
If you want to point me to the right location to add documentation,
I'm happy to write some. (I can write some for _UNICODE as well, if
you like.)
Aaron Meadows
-Original Message-
From: David Cole [mailto:david.c...@kitware.com]
Sent: Wednesday, August 31, 2011 1:04 PM
To: Meadows, Aaron C.
Cc: cmake@cmake.org
Subject: Re: [CMake] Bug #12189
The CMake/Tests/CMakeLists.txt file lists most of the tests that
execute on our dashboards.
The directories under CMake/Tests are all the existing test source
trees. If you want to modify one of the existing tests to have an
_SBCS target compile definition, I'd start by looking at Simple or
COnly as a simple basis for a new test.
Or you may find another one where the code that's compiled and tested
is compatible with _SBCS.
You may want to conditionalize it with code like:
if (CMAKE_GENERATOR MATCHES Visual Studio) or
if (MSVC)
since your changes only apply to the Visual Studio generators. It
should work with cl and nmake too, though, to have an _SBCS
definition. Other compilers may or may not like a -D_SBCS.
Let me know if you need further guidance.
Thanks,
David
On Wed, Aug 31, 2011 at 1:33 PM, aaron.mead...@thomsonreuters.com
wrote:
I'm happy to assist in any way I can. Where do I need to add a
test? Also, where would it be appropriate to document this?
Aaron Meadows
-Original Message-
From: David Cole [mailto:david.c...@kitware.com]
Sent: Wednesday, August 31, 2011 11:02 AM
To: Meadows, Aaron C.
Cc: cmake@cmake.org
Subject: Re: [CMake] Bug #12189
Your patch has the wrong sense I think It looks like it's
removing _SBCS code, but you want to add all that code, correct?
I
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Wed, Sep 07, 2011 at 11:04:42PM -0400, Jean-Christophe Fillion-Robin wrote: -- Forwarded message -- From: Peter Collingbourne pe...@pcc.me.uk Date: Wed, Sep 7, 2011 at 9:17 PM Subject: Proposal: restat rules To: ninja-bu...@googlegroups.com FWIW, the Ninja generator I have been working on is based on work by Nicolas Despres, and has been successfully used to compile a number of large open source projects, including CMake itself, LLVM/Clang, OpenCV and Bullet Physics. I am planning to submit the Ninja generator as a patch to CMake upstream once it has been put through more exhaustive testing and certain known issues have been resolved (my post to ninja-build being one of them). Anyone who is interested in trying the Ninja generator with their own projects is welcome to clone my repository at: https://github.com/pcc/CMake/tree/ninja-generator and to report any issues encountered. Note that the generator is currently only known to work on Linux. To select the Ninja generator you can pass the option -G Ninja on the cmake command line. Thanks, -- Peter ___ 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] novice question: modification of FLAGS rule variable?
The project is adding it, and I will check on how it is doing it. Its only C
files.
-David
From: Glenn Coombs [mailto:glenn.coo...@gmail.com]
Sent: Thursday, September 08, 2011 11:41 AM
To: David Dunkle
Cc: David Cole; cmake@cmake.org
Subject: Re: [CMake] novice question: modification of FLAGS rule variable?
Is the -m32 flag being provided as a default by cmake, or are you specifying it
yourself ? If the latter, then maybe it has been added to the
COMPILE_DEFINITIONS property instead of the CMAKE_C_FLAGS variable. I have
seen CMakeList.txt files use add_definitions(-m32) rather than adding it to the
CMAKE_C_FLAGS variable. That would explain why explicitly setting
CMAKE_C_FLAGS wasn't removing it. Also, is it C files or C++ files that are
being compiled, because C++ files use CMAKE_CXX_FLAGS instead of CMAKE_C_FLAGS.
On 8 September 2011 18:16, David Dunkle
ddun...@arxan.commailto:ddun...@arxan.com wrote:
I inherited this cmake build that builds a complex project with a fairly large
directory tree. Part way through it switches compilers, with code similar to
what is below, and builds a few subdirectories using the new compilers. The
compiler flags for the original compilers (compiler A) bleeds through to the
new compilers (compiler B), because of the FLAGS below. The code below is in
the CMakeLists.txt of the subdirectory that switches to the new compiler.
Now I need to build on a new platform, which involves adding only one new
compiler flag (-m32) to compiler A. Unfortunately, the -m32 is picked up by the
FLAGS below and passed to compiler B, which does not support this flag, and
gives an error.
So, I am trying to figure out if I can modify the existing code to remove the
-m32 from FLAGS for compiler B, or if I need to basically rewrite the
compiler B part of the build so that the subdirectories using compiler B are a
separate cmake project. The rewrite idea is hard to justify in schedule sense
to remove one flag, and I have to be sure it's necessary.
While conceptually removing one -m32 flag seems simple, I am having a very hard
time figuring out how to do it in cmake. Removing the single flag from compiler
B can take two forms, as we have discussed. I can obtain the existing flags and
remove the -m32 or I can substitute the new flags completely.
The removal option has not worked so far, possibly because this removal is
occurring in a subdirectory of the original long after the project is
established, and possibly because I am not sure which variable to modify. The
CMAKE_C_FLAGS is already modified in this case, to no effect on FLAGS,
possibly because its occurring long after the project is established. Can I
get_target_property on COMPILER_FLAGS and modify that?
The second option almost works, but I can't figure out how to obtain the
-DDEBUG option that is currently established with set_target_properties, as
described below.
-David
From: Glenn Coombs
[mailto:glenn.coo...@gmail.commailto:glenn.coo...@gmail.com]
Sent: Thursday, September 08, 2011 3:15 AM
To: David Dunkle
Cc: David Cole; cmake@cmake.orgmailto:cmake@cmake.org
Subject: Re: [CMake] novice question: modification of FLAGS rule variable?
The set_target_properties() of COMPILE_FLAGS allows you to add the -DDEBUG just
for the mylibd target (although you should really use the COMPILE_DEFINITIONS
property for preprocessor symbols). Why do you need to mess with the FLAGS
part of the compile command ? Can't you add extra compiler command flags like
this:
set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -myFlag)
or even replace the default flags entirely like this:
set(CMAKE_C_FLAGS -foo)
I'm not sure what you are trying to achieve. Can you explain in a bit more
detail ?
--
Glenn
On 8 September 2011 04:35, David Dunkle
ddun...@arxan.commailto:ddun...@arxan.com wrote:
Thanks, Glenn. That almost works. However, the values of FLAGS is hard to
construct in this case. It looks something like this:
add_library(mylib, STATIC, ${files})
set_target_properties(mylib
PROPERTIES PREFIX
COMPILE_FLAGS ${target_compiler_flags})
add_library(mylibd, STATIC, ${files})
set_target_properties(mylibd,
PROPERTIES PREFIX
COMPILE_FLAGS -DDEBUG
${target_compiler_flags})
...
set(CMAKE_C_COMPILE_OBJECT ${target_compiler} -c FLAGS -o OBJECT)
I can replace FLAGS with ${target_compiler_flags} yielding this:
set(CMAKE_C_COMPILE_OBJECT ${target_compiler} -c ${target_compiler_flags} -o
OBJECT)
but then the -DDEBUG is missing for the build of mylibd. I guess both mylibd
and mylib use CMAKE_C_COMPILE_OBJECT and I need a way to pass the -DDEBUG to
the compile of one and not the other.
-David
From: Glenn Coombs
[mailto:glenn.coo...@gmail.commailto:glenn.coo...@gmail.com]
Sent: Wednesday, September 07, 2011 4:19 AM
To: David Cole
Cc: David Dunkle;
Re: [CMake] question about Eclipse CDT Generators
CMake generates all the Makefiles by itself and then creates a standard Makefile-Project for Eclipse/CDT on top of them. This is different from (native) 'Managed Build' in Eclipse/CDT where the project configuration and dependency tree is pure XML and the underlying toolchain is integrated by adapter-classes in Java. ___ 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
[CMake] cmake -E rename with wildcard adds quotes to argument
Essentially what I've tried to do is:
ExternalProject_Add(aproject
...)
ExternalProject_Add_Step(aproject customstep
DEPENDEES build
COMMAND ${CMAKE_COMMAND} -E rename foo-* foo
...)
This appears to have generated the following:
cd /path/to/working/directory /usr/bin/cmake -E rename foo-* foo
...which causes the following error:
Error renaming from foo-* to foo: No such file or directory
If I run the cmake -E rename on the command line without quotes it works as
expected.
Is it possible to generate the command without the added quotes or is this
actually protecting me from my own ignorance? Is there another way to
accomplish this task? Basically, the project I'm trying to add needs to be
installed manually but the directories containing the built libraries will vary
depending on the system. I was trying to rename this directory using a
wildcard so that I could then copy its contents to the desired location.
-Jose
___
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] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Thu, Sep 8, 2011 at 2:54 PM, Peter Collingbourne pe...@pcc.me.uk wrote: I am planning to submit the Ninja generator as a patch to CMake upstream once it has been put through more exhaustive testing and certain known issues have been resolved (my post to ninja-build being one of them). Very cool! What differences (if any) have you seen incompilation speed? Cheers, CY ___ 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] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
Tested cmake/ninja with Blender's cmake files, works well, and fast! Single file rebuild is 0.97 sec, same on makefiles was 3.7sec. btw, we do something similar to LLVM with generating source, only updating if it changes, however only for C files not headers, ninja handles this ok for my quick tests editing files and rebuilding. Looking forward to having this in stable cmake! On Fri, Sep 9, 2011 at 4:54 AM, Peter Collingbourne pe...@pcc.me.uk wrote: On Wed, Sep 07, 2011 at 11:04:42PM -0400, Jean-Christophe Fillion-Robin wrote: -- Forwarded message -- From: Peter Collingbourne pe...@pcc.me.uk Date: Wed, Sep 7, 2011 at 9:17 PM Subject: Proposal: restat rules To: ninja-bu...@googlegroups.com FWIW, the Ninja generator I have been working on is based on work by Nicolas Despres, and has been successfully used to compile a number of large open source projects, including CMake itself, LLVM/Clang, OpenCV and Bullet Physics. I am planning to submit the Ninja generator as a patch to CMake upstream once it has been put through more exhaustive testing and certain known issues have been resolved (my post to ninja-build being one of them). Anyone who is interested in trying the Ninja generator with their own projects is welcome to clone my repository at: https://github.com/pcc/CMake/tree/ninja-generator and to report any issues encountered. Note that the generator is currently only known to work on Linux. To select the Ninja generator you can pass the option -G Ninja on the cmake command line. Thanks, -- Peter ___ 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 -- - Campbell ___ 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
[Cmake-commits] CMake branch, next, updated. v2.8.5-1859-g1118ff1
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 1118ff1c65aebe810e2383eee15a92aa2891bc36 (commit)
via 71402eb25244e5805df54c2f6e62ddd36201dbd6 (commit)
from ec8434567837e8305a2d67734d49f0b70ad7fe3b (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1118ff1c65aebe810e2383eee15a92aa2891bc36
commit 1118ff1c65aebe810e2383eee15a92aa2891bc36
Merge: ec84345 71402eb
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Sep 8 15:04:51 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Sep 8 15:04:51 2011 -0400
Merge topic 'FortranCInterface-VS' into next
71402eb FortranCInterface: Compile separate Fortran lib in VerifyC[XX]
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=71402eb25244e5805df54c2f6e62ddd36201dbd6
commit 71402eb25244e5805df54c2f6e62ddd36201dbd6
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Sep 8 14:56:48 2011 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Sep 8 14:56:48 2011 -0400
FortranCInterface: Compile separate Fortran lib in VerifyC[XX]
The Intel Fortran plugin for Visual Studio requires Fortran source files
to be compiled in a separate target from C and C++ code. Compile the
VerifyFortran.f source file in a separate library and link the main
VerifyFortanC executable to it.
diff --git a/Modules/FortranCInterface/Verify/CMakeLists.txt
b/Modules/FortranCInterface/Verify/CMakeLists.txt
index 052dd59..e969f24 100644
--- a/Modules/FortranCInterface/Verify/CMakeLists.txt
+++ b/Modules/FortranCInterface/Verify/CMakeLists.txt
@@ -24,7 +24,9 @@ include(FortranCInterface)
FortranCInterface_HEADER(VerifyFortran.h SYMBOLS VerifyFortran)
include_directories(${VerifyFortranC_BINARY_DIR})
-add_executable(VerifyFortranC main.c VerifyC.c VerifyFortran.f ${VerifyCXX})
+add_library(VerifyFortran STATIC VerifyFortran.f)
+add_executable(VerifyFortranC main.c VerifyC.c ${VerifyCXX})
+target_link_libraries(VerifyFortranC VerifyFortran)
if(NOT VERIFY_CXX)
# The entry point (main) is defined in C; link with the C compiler.
---
Summary of changes:
Modules/FortranCInterface/Verify/CMakeLists.txt |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.5-1862-gcc016d0
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via cc016d0e3cc1fd9a68b0d4a806e14cc62ac39bbb (commit) via 59204e11265eee5f8a482cf52b5daf5d57ed85c7 (commit) via 3246dc26651c50cebd99b64ca8fb1a05873f192f (commit) from 1118ff1c65aebe810e2383eee15a92aa2891bc36 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cc016d0e3cc1fd9a68b0d4a806e14cc62ac39bbb commit cc016d0e3cc1fd9a68b0d4a806e14cc62ac39bbb Merge: 1118ff1 59204e1 Author: Eric Noulard eric.noul...@gmail.com AuthorDate: Thu Sep 8 16:49:35 2011 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Sep 8 16:49:35 2011 -0400 Merge topic 'CPack-DocFix-bug12449' into next 59204e1 CPack fix #12449 doc mispelled 3246dc2 KWSys Nightly Date Stamp http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=59204e11265eee5f8a482cf52b5daf5d57ed85c7 commit 59204e11265eee5f8a482cf52b5daf5d57ed85c7 Author: Eric NOULARD eric.noul...@gmail.com AuthorDate: Thu Sep 8 22:00:34 2011 +0200 Commit: Eric NOULARD eric.noul...@gmail.com CommitDate: Thu Sep 8 22:00:34 2011 +0200 CPack fix #12449 doc mispelled CPACK_INSTALL_DIRECTORIES--CPACK_INSTALLED_DIRECTORIESœ diff --git a/Modules/CPack.cmake b/Modules/CPack.cmake index d82de93..2cc27cf 100644 --- a/Modules/CPack.cmake +++ b/Modules/CPack.cmake @@ -215,7 +215,7 @@ # # CPACK_INSTALL_COMMANDS - Extra commands to install components. # -# CPACK_INSTALL_DIRECTORIES - Extra directories to install. +# CPACK_INSTALLED_DIRECTORIES - Extra directories to install. # #= --- Summary of changes: Modules/CPack.cmake |2 +- Source/kwsys/kwsysDateStamp.cmake |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.5-445-g3ae6060
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 3ae6060f298e202973fcfdf8d863b3178a107382 (commit) from 3246dc26651c50cebd99b64ca8fb1a05873f192f (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3ae6060f298e202973fcfdf8d863b3178a107382 commit 3ae6060f298e202973fcfdf8d863b3178a107382 Author: KWSys Robot kwro...@kitware.com AuthorDate: Fri Sep 9 00:01:24 2011 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Fri Sep 9 00:14:04 2011 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 0599668..a11cf10 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 09) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 08) +SET(KWSYS_DATE_STAMP_DAY 09) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
