Re: [cmake-developers] find_package module-only policy
On 2/21/2012 5:09 PM, Alexander Neundorf wrote: This is now in the FindPackage_CONFIG_MODULEKeywordsFirst branch on stage, [snip] There is the potential issue with CONFIG and MODULE being in use as module names already somewhere. Yes. I hadn't actually intended for you to go straight to implementation with that idea. I only intended it as a possibility for discussion. Your concern also makes me realize that find_package has always had the package name first. There are many other ways to imply CONFIG mode by using some of the full signature arguments. I think the original find_package(Foo CONFIG) ordering is better in light of these concerns. 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] find_package module-only policy
On 2/21/2012 4:22 PM, Alexander Neundorf wrote: Problem ? Somebody has a FindConfig.cmake here: http://lists.gforge.inria.fr/pipermail/blobseer-commits/2009- January/000101.html There may be also a FindCONFIG.cmake or a FindMODULE.cmake somewhere... Ignore and just hope it will be ok ? No, I think the package-name-first-always ordering is better. I hadn't thought of the case sensitivity concern before. 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 branch in stage
On Thu, Feb 16, 2012 at 4:11 PM, Stephen Kelly steve...@gmail.com wrote: David Cole wrote: Pushed down the queue again... I'll get to it soon. There are a handful of minor changes that I still need to make first. Ok. Let me know if it's anything I can do. 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 Finally pushed the most recent commits this morning... Please see the target-include-directories branch on the stage. (Not yet merged to 'next' -- but soon will be.) Question (probably for Brad): What should --help-property emit now that there are both directory and target level properties for INCLUDE_DIRECTORIES? Here's what it does: $ bin/Debug/cmake --help-property INCLUDE_DIRECTORIES cmake version 2.8.7.20120222-g56a44 INCLUDE_DIRECTORIES List of preprocessor include file search directories. This read-only property specifies the list of directories given so far to the include_directories command. It is intended for debugging purposes. So the most recent commit in the topic branch, which adds documentation for the target level property, appears useless... Should we eliminate the directory level documentation as well? Or emit both? If so, how? After we settle this one remaining point, I'll patch up the topic branch and merge it to 'next'. Thanks to everybody for your help and patience in getting this feature into CMake. Cheers, David C. -- 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 branch in stage
On 2/22/2012 8:05 AM, David Cole wrote: So the most recent commit in the topic branch, which adds documentation for the target level property, appears useless... Should we eliminate the directory level documentation as well? Or emit both? Emit both and explain their interaction. The documentation for each will be a bit different because each plays a unique role. The include_directories command should document just how it sets the dir-level and target-level properties. The dir-level property should document that it is used to init the target-level property for new targets. The target-level one should document that it is used as the actual source of include directories for compilation. -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] Knowing if a C project is being built
Brad King wrote: On Wed, Feb 22, 2012 at 11:32 AM, Rolf Eike Beer e...@sf-mail.de wrote: Use CMAKE_LANG_COMPILER_LOADED to determine which languages are enabled. In the last modification in FindOpenMP I used the ENABLED_LANGUAGES property. Which of both ways is the preferred one? I have no preference. Both are documented and should work. If the goal is to loop over all the enabled languages use the property. Otherwise the variable can be tested for a specific language. Of course the property is read-only so projects cannot mess with it like they can by setting the variable ;) Then I'll use the variables because it is less code ;) Eike -- signature.asc Description: This is a digitally signed message part. -- 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] find_package module-only policy
On Wednesday 22 February 2012, Brad King wrote: On 2/21/2012 5:09 PM, Alexander Neundorf wrote: This is now in the FindPackage_CONFIG_MODULEKeywordsFirst branch on stage, [snip] There is the potential issue with CONFIG and MODULE being in use as module names already somewhere. Yes. I hadn't actually intended for you to go straight to implementation with that idea. I only intended it as a possibility for discussion. From my side I had no need to discuss, I really like this idea. I mean, I really like this suggestion. Only problem is the FindCONFIG.cmake and FindMODULE.cmake case... If we can find a way how to avoid this problem I'd be all for this solution. Enabling the keywords MODULE and CONFIG only via a policy ? It could warn if the name of the package is one of the known keywords or looks like a version number. Not that nice, but maybe acceptable for those uncommon package names ? Or make the keyword more unique, i.e. longer ? find_package(CONFIG_MODE|MODULE_MODE Foo) Doesn't look that nice, but should be safe enough. Other ideas ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories branch in stage
On Wed, Feb 22, 2012 at 8:05 AM, David Cole david.c...@kitware.com wrote: On Thu, Feb 16, 2012 at 4:11 PM, Stephen Kelly steve...@gmail.com wrote: David Cole wrote: Pushed down the queue again... I'll get to it soon. There are a handful of minor changes that I still need to make first. Ok. Let me know if it's anything I can do. 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 Finally pushed the most recent commits this morning... Please see the target-include-directories branch on the stage. (Not yet merged to 'next' -- but soon will be.) Question (probably for Brad): What should --help-property emit now that there are both directory and target level properties for INCLUDE_DIRECTORIES? Here's what it does: $ bin/Debug/cmake --help-property INCLUDE_DIRECTORIES cmake version 2.8.7.20120222-g56a44 INCLUDE_DIRECTORIES List of preprocessor include file search directories. This read-only property specifies the list of directories given so far to the include_directories command. It is intended for debugging purposes. So the most recent commit in the topic branch, which adds documentation for the target level property, appears useless... Should we eliminate the directory level documentation as well? Or emit both? If so, how? After we settle this one remaining point, I'll patch up the topic branch and merge it to 'next'. Thanks to everybody for your help and patience in getting this feature into CMake. Cheers, David C. Finally ready... I just force-pushed the 'target-include-directories' branch to stage again. I think it's ready for merging to 'next' -- before I do that, could I get a sanity check that the documentation in the top commit (ff44b88) is acceptable? 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories branch in stage
On Wed, Feb 22, 2012 at 3:04 PM, David Cole david.c...@kitware.com wrote: On Wed, Feb 22, 2012 at 8:05 AM, David Cole david.c...@kitware.com wrote: On Thu, Feb 16, 2012 at 4:11 PM, Stephen Kelly steve...@gmail.com wrote: David Cole wrote: Pushed down the queue again... I'll get to it soon. There are a handful of minor changes that I still need to make first. Ok. Let me know if it's anything I can do. 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 Finally pushed the most recent commits this morning... Please see the target-include-directories branch on the stage. (Not yet merged to 'next' -- but soon will be.) Question (probably for Brad): What should --help-property emit now that there are both directory and target level properties for INCLUDE_DIRECTORIES? Here's what it does: $ bin/Debug/cmake --help-property INCLUDE_DIRECTORIES cmake version 2.8.7.20120222-g56a44 INCLUDE_DIRECTORIES List of preprocessor include file search directories. This read-only property specifies the list of directories given so far to the include_directories command. It is intended for debugging purposes. So the most recent commit in the topic branch, which adds documentation for the target level property, appears useless... Should we eliminate the directory level documentation as well? Or emit both? If so, how? After we settle this one remaining point, I'll patch up the topic branch and merge it to 'next'. Thanks to everybody for your help and patience in getting this feature into CMake. Cheers, David C. Finally ready... I just force-pushed the 'target-include-directories' branch to stage again. I think it's ready for merging to 'next' -- before I do that, could I get a sanity check that the documentation in the top commit (ff44b88) is acceptable? Thanks, David All set. One more force-push after cleaning up a commit on Brad's recommendation and it is now finally merged to 'next'. Whew. Thx, 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package module-only policy
On Wednesday 22 February 2012, Brad King wrote: On 2/22/2012 12:47 PM, Alexander Neundorf wrote: From my side I had no need to discuss, I really like this idea. I mean, I really like this suggestion. Only problem is the FindCONFIG.cmake and FindMODULE.cmake case... If we can find a way how to avoid this problem I'd be all for this solution. Enabling the keywords MODULE and CONFIG only via a policy ? I think that's too complicated for now. It is much simpler to just put the keywords at the same place as NO_MODULE currently goes. Yes, probably. I will think a bit more about it... We can always add the mode-first signatures later. I think if possible we should change it only once. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] find_package module-only policy
On 2/22/2012 4:30 PM, Alexander Neundorf wrote: On Wednesday 22 February 2012, Brad King wrote: I think that's too complicated for now. It is much simpler to just put the keywords at the same place as NO_MODULE currently goes. Yes, probably. I will think a bit more about it... Actually thinking more about the signature I like the package-first approach better even when the CONFIG or MODULE keyword is used. Let's not bike-shed this anymore. We're just adding more names like NO_MODULE. I'd rather focus on the error message wording which is more important. -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] Attention ninja-generator developers
Hi there, When I merged the 'target-include-directories' branch to 'next' today, I got build errors on the Continuous dashboards related to the new ninja generator. (Some method signatures changed and had to be updated.) To resolve the errors, I had to get the 'ninja-generator' branch from the stage, merge my 'target-include-directories' branch into it, fix the error, and then push a new updated ninja-generator branch to the stage and merge it to 'next' again. If you are working on that branch, make sure to get the latest tip of it from the stage, and then continue development from there. Thanks -- and let me know if you need any help with this... David C. -- 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 branch in stage
David Cole wrote: All set. One more force-push after cleaning up a commit on Brad's recommendation and it is now finally merged to 'next'. Whew. Great! Thanks for all yor work on getting this through the last mile (or was it more? :)). 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] Embarcadero C++ nightly test
Hello, In this ticket http://www.cmake.org/Bug/view.php?id=12604#c27908, it says we'd like someone who has this compiler (Embarcadero C++) to run a nightly dashboard submission so we can keep it working. Otherwise it will not be officially supported. But why do not the official nightly testing machine do this? The compiler could be downloaded from here: http://www.embarcadero.com/products/cbuilder/downloads Although it says the trial is a 30-day trial, in fact, the command line tool of the downloaded package, as far as I know, could be run for unlimited time without paying any money.So why not test it officially? Thanks! Hong -- 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] Embarcadero C++ nightly test
On 23 February 2012 13:27, H Xu xuh...@gmail.com wrote: The compiler could be downloaded from here: http://www.embarcadero.com/products/cbuilder/downloads Although it says the trial is a 30-day trial, in fact, the command line tool of the downloaded package, as far as I know, could be run for unlimited time without paying any money.So why not test it officially? The fact it is technically possible, without a nag screen, etc. does not mean it is legal. So, better check the EULA. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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] Announce: Kitware Holding CMake course April 2 in Lyon France
Kitware will be holding a developers training course on April 2, 2012 in Lyon, France. This 1-day course will cover CMake, CTest, CPack and CDash. Please visit our web site for more information and registration details (early registration ends March 19th!) at either: http://www.kitware.com/products/protraining.php?course=04/02/2012 (in English) or http://www.kitware.fr/products/protraining.php?course=04/02/2012 (in French) Note that the course will be taught in English. If you have any questions, please contact us at courses at kitware.com or formations at kitware.fr -Bill -- 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] cpack issues
Alright then I now actually get an installer which I can click on, and
cpack doesn't give any more errors.
However, when I try to run the executable I get a
executable..exe The specified path does not exist..
which is quite a weird error, because it's the same path that I'm
clicking, and it does exists :S
Has anyone seen this?
I just changed the destination to the ${PROJECT_NAME}:
install(
DIRECTORY ${EGG_BUILD_DIRECTORY}
DESTINATION ${PROJECT_NAME}
)
but in general, how would I make sure that the final installer will try
to install the software
in $ENV{USERPROFILE} for example?
Writing it in the destination is clearly wrong, but is there another way
then?
Thanks,
Andrea
--
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] checking arguments
I find not so nice that CMake doesn't complain at all if some variables
are not defined.
Is there a way to make it complain if a variable used is actually blank?
In the meanwhile I ended up with this:
set(COMPULSORY_ARGUMENTS PSI)
set(OPTIONAL_ARGUMENTS WORKSPACE CONTAINER_PATHS)
macro (check_compulsory_variable var)
if (NOT DEFINED ${var})
message(FATAL_ERROR variable ${var} is not defined)
endif ()
endmacro ()
macro (check_optional_variable var)
if (NOT DEFINED ${var})
message(WARNING variable ${var} is not defined)
endif ()
endmacro ()
foreach (arg ${COMPULSORY_ARGUMENTS})
check_compulsory_variable(${arg})
endforeach ()
foreach (arg ${OPTIONAL_ARGUMENTS})
check_optional_variable(${arg})
endforeach ()
which is not great but it does the job.
Any better solutions?
--
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] passing arguments to the final make
I would like to be able to pass arguments to my generated Makefile.
Suppose I use an environment variable like this:
add_custom_target(run_dev_script
COMMAND ${PYTHON_EXECUTABLE} ${PREREQUISITE}
COMMAND ${PYTHON_EXECUTABLE} ${SCRIPT}
)
Would that actually work?
In theory ${SCRIPT} is substituted at cmake time, so I have the
impression that it wouldn't work..
I don't find anything useful in cmake -E however, that would allow me to
do something at make time.
Any suggestions?
--
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] checking arguments
On Wed, Feb 22, 2012 at 10:36 AM, Andrea Crotti
andrea.crott...@gmail.com wrote:
I find not so nice that CMake doesn't complain at all if some variables are
not defined.
Is there a way to make it complain if a variable used is actually blank?
In the meanwhile I ended up with this:
set(COMPULSORY_ARGUMENTS PSI)
set(OPTIONAL_ARGUMENTS WORKSPACE CONTAINER_PATHS)
macro (check_compulsory_variable var)
if (NOT DEFINED ${var})
message(FATAL_ERROR variable ${var} is not defined)
endif ()
endmacro ()
macro (check_optional_variable var)
if (NOT DEFINED ${var})
message(WARNING variable ${var} is not defined)
endif ()
endmacro ()
foreach (arg ${COMPULSORY_ARGUMENTS})
check_compulsory_variable(${arg})
endforeach ()
foreach (arg ${OPTIONAL_ARGUMENTS})
check_optional_variable(${arg})
endforeach ()
which is not great but it does the job.
Any better solutions?
--
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 could try using the command line flags --warn-uninitialized
and/or --warn-unused-vars to produce warnings about such
situations...
--
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] delayed target
On 02/22/2012 05:02 PM, Andrea Crotti wrote:
Again I'm having some troubles with the different building stages:
I would like to have a target that simply unzips all the files contained
in a directory,
which can be found with a simple globbing.
add_custom_target(unzip_all_eggs
file(GLOB eggs RELATIVE ${EGG_BUILD_DIRECTORY}/*egg)
COMMAND ${PYTHON_EXECUTABLE} ${UNZIP_SCRIPT} ${egg}
)
The problem is that [...]
...FILE(GLOB ...) is a CMake command executed by CMake, whereas the
custom target's COMMANDs are executed by the build tool at build
time, so this approach fails from the first.
A possible solution is to make my UNZIP_SCRIPT smarter and just do the
globbing
itself, is there any other more CMake-like solution?
ADD_CUSTOM_TARGET(unzip_all_eggs
${CMAKE_COMMAND}
-DEGGDIR=${EGG_BUILD_DIRECTORY}
-P ${CMAKE_SOURCE_DIR}/unzip_all_eggs.cmake)
# ${CMAKE_SOURCE_DIR}/unzip_all_eggs.cmake:
SET(PYTHON_EXECUTABLE ...)
SET(UNZIP_SCRIPT ...)
FILE(GLOB eggs RELATIVE ${EGGDIR}/*egg)
EXECUTE_PROCESS(
COMMAND ${PYTHON_EXECUTABLE} ${UNZIP_SCRIPT} ${eggs}
WORKING_DIRECTORY ...
)
You might want to provide an unzip_all_eggs.cmake.in template including
SET(PYTHON_EXECUTABLE @PYTHON_EXECUTABLE@)
SET(UNZIP_SCRIPT @UNZIP_SCRIPT@)
use CONFIGURE_FILE(unzip_all_eggs.cmake.in unzip_all_eggs.cmake @ONLY)
to generate the actual unzip_all_eggs.cmake after searching Python and
your script, and specify -P ${CMAKE_BINARY_DIR}/unzip_all_eggs.cmake.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] passing arguments to the final make
On 02/22/2012 04:43 PM, Andrea Crotti wrote:
I would like to be able to pass arguments to my generated Makefile.
Suppose I use an environment variable like this:
add_custom_target(run_dev_script
COMMAND ${PYTHON_EXECUTABLE} ${PREREQUISITE}
COMMAND ${PYTHON_EXECUTABLE} ${SCRIPT}
)
Would that actually work?
In theory ${SCRIPT} is substituted at cmake time, so I have the
impression that it wouldn't work..
I don't find anything useful in cmake -E however, that would allow me to
do something at make time.
Any suggestions?
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
ADD_CUSTOM_TARGET(echo ${CMAKE_COMMAND} -E echo \${ECHO})
After initial configuration:
% make echo ECHO=Hello World
Scanning dependencies of target echo
Hello World
Built target echo
% make echo ECHO=Goodbye World
Goodbye World
Built target echo
% make echo ECHO=Regards, Michael
Regards, Michael
Built target echo
--
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] passing arguments to the final make
On 02/22/2012 05:25 PM, Michael Hertling wrote:
On 02/22/2012 04:43 PM, Andrea Crotti wrote:
I would like to be able to pass arguments to my generated Makefile.
Suppose I use an environment variable like this:
add_custom_target(run_dev_script
COMMAND ${PYTHON_EXECUTABLE} ${PREREQUISITE}
COMMAND ${PYTHON_EXECUTABLE} ${SCRIPT}
)
Would that actually work?
In theory ${SCRIPT} is substituted at cmake time, so I have the
impression that it wouldn't work..
I don't find anything useful in cmake -E however, that would allow me to
do something at make time.
Any suggestions?
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
ADD_CUSTOM_TARGET(echo ${CMAKE_COMMAND} -E echo \${ECHO})
After initial configuration:
% make echo ECHO=Hello World
Scanning dependencies of target echo
Hello World
Built target echo
% make echo ECHO=Goodbye World
Goodbye World
Built target echo
% make echo ECHO=Regards, Michael
Regards, Michael
Built target echo
Ah that's nice thanks, I'm not sure though that I can rely on being =
2.8 always,
and that's probably a requirement, right?
--
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] passing arguments to the final make
On 02/22/2012 06:32 PM, Andrea Crotti wrote:
On 02/22/2012 05:25 PM, Michael Hertling wrote:
On 02/22/2012 04:43 PM, Andrea Crotti wrote:
I would like to be able to pass arguments to my generated Makefile.
Suppose I use an environment variable like this:
add_custom_target(run_dev_script
COMMAND ${PYTHON_EXECUTABLE} ${PREREQUISITE}
COMMAND ${PYTHON_EXECUTABLE} ${SCRIPT}
)
Would that actually work?
In theory ${SCRIPT} is substituted at cmake time, so I have the
impression that it wouldn't work..
I don't find anything useful in cmake -E however, that would allow me to
do something at make time.
Any suggestions?
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P NONE)
ADD_CUSTOM_TARGET(echo ${CMAKE_COMMAND} -E echo \${ECHO})
After initial configuration:
% make echo ECHO=Hello World
Scanning dependencies of target echo
Hello World
Built target echo
% make echo ECHO=Goodbye World
Goodbye World
Built target echo
% make echo ECHO=Regards, Michael
Regards, Michael
Built target echo
Ah that's nice thanks, I'm not sure though that I can rely on being =
2.8 always,
and that's probably a requirement, right?
It's sufficient that \$ makes it to the Makefile and becomes $ there.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] passing arguments to the final make
On 02/22/2012 05:32 PM, Andrea Crotti wrote:
Ah that's nice thanks, I'm not sure though that I can rely on being =
2.8 always,
and that's probably a requirement, right?
I tried what you suggested and with this:
add_custom_target(dev_no_run
COMMAND ${PYTHON_EXECUTABLE} ${DEV_MAIN} -w ${WORKSPACE}
${APPLICATION} --develop_only -l info
COMMAND ${PYTHON_EXECUTABLE} \${SCRIPT}
)
I get this in the Makefile:
CMakeFiles/dev_no_run:
/usr/bin/python
/home/andrea/git_projs/PSI_Hamburg/utils/utils/bin/dev_main.py -w
/home/andrea/git_projs
/home/andrea/git_projs/Minimum_Drag/airbus.application.minimum_drag
--develop_only -l info
/usr/bin/python ${SCRIPT}
which is probably not what I want, because for a Makefile it should be
$(SCRIPT), right?
--
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] delayed target
On 02/22/2012 05:14 PM, Michael Hertling wrote:
On 02/22/2012 05:02 PM, Andrea Crotti wrote:
Again I'm having some troubles with the different building stages:
I would like to have a target that simply unzips all the files contained
in a directory,
which can be found with a simple globbing.
add_custom_target(unzip_all_eggs
file(GLOB eggs RELATIVE ${EGG_BUILD_DIRECTORY}/*egg)
COMMAND ${PYTHON_EXECUTABLE} ${UNZIP_SCRIPT} ${egg}
)
The problem is that [...]
...FILE(GLOB ...) is a CMake command executed by CMake, whereas the
custom target's COMMANDs are executed by the build tool at build
time, so this approach fails from the first.
A possible solution is to make my UNZIP_SCRIPT smarter and just do the
globbing
itself, is there any other more CMake-like solution?
ADD_CUSTOM_TARGET(unzip_all_eggs
${CMAKE_COMMAND}
-DEGGDIR=${EGG_BUILD_DIRECTORY}
-P ${CMAKE_SOURCE_DIR}/unzip_all_eggs.cmake)
# ${CMAKE_SOURCE_DIR}/unzip_all_eggs.cmake:
SET(PYTHON_EXECUTABLE ...)
SET(UNZIP_SCRIPT ...)
FILE(GLOB eggs RELATIVE ${EGGDIR}/*egg)
EXECUTE_PROCESS(
COMMAND ${PYTHON_EXECUTABLE} ${UNZIP_SCRIPT} ${eggs}
WORKING_DIRECTORY ...
)
You might want to provide an unzip_all_eggs.cmake.in template including
SET(PYTHON_EXECUTABLE @PYTHON_EXECUTABLE@)
SET(UNZIP_SCRIPT @UNZIP_SCRIPT@)
use CONFIGURE_FILE(unzip_all_eggs.cmake.in unzip_all_eggs.cmake @ONLY)
to generate the actual unzip_all_eggs.cmake after searching Python and
your script, and specify -P ${CMAKE_BINARY_DIR}/unzip_all_eggs.cmake.
Thanks, this is really nice in general and I might use it in the future.
The problem is that in this specific case it doesn't buy me much and
adds complexity, because
I would still have only one target unzipping all the eggs.
It would be nice to be able to generate N target 1 for each egg.
Anyway I think that just modifying the python unzip script to do the
globbing is the
easier way to go in this case..
--
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] make a python script executable
So now suppose I have a working installer (which is not the case yet), and that the entry point of the whole program is a python script. Is there a way to make the whole project launchable via double click on more platforms? At the moment there is a run.bat in every project for this to run on Windows, and I guess it's not so easy otherwise http://www.pyinstaller.org/ would not exist. But since cmake can run the python script in a multi-platform way, maybe there is a way to create an actual executable that does the job, right? -- 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] delayed target
On 02/22/2012 07:21 PM, Andrea Crotti wrote:
On 02/22/2012 05:14 PM, Michael Hertling wrote:
On 02/22/2012 05:02 PM, Andrea Crotti wrote:
Again I'm having some troubles with the different building stages:
I would like to have a target that simply unzips all the files contained
in a directory,
which can be found with a simple globbing.
add_custom_target(unzip_all_eggs
file(GLOB eggs RELATIVE ${EGG_BUILD_DIRECTORY}/*egg)
COMMAND ${PYTHON_EXECUTABLE} ${UNZIP_SCRIPT} ${egg}
)
The problem is that [...]
...FILE(GLOB ...) is a CMake command executed by CMake, whereas the
custom target's COMMANDs are executed by the build tool at build
time, so this approach fails from the first.
A possible solution is to make my UNZIP_SCRIPT smarter and just do the
globbing
itself, is there any other more CMake-like solution?
ADD_CUSTOM_TARGET(unzip_all_eggs
${CMAKE_COMMAND}
-DEGGDIR=${EGG_BUILD_DIRECTORY}
-P ${CMAKE_SOURCE_DIR}/unzip_all_eggs.cmake)
# ${CMAKE_SOURCE_DIR}/unzip_all_eggs.cmake:
SET(PYTHON_EXECUTABLE ...)
SET(UNZIP_SCRIPT ...)
FILE(GLOB eggs RELATIVE ${EGGDIR}/*egg)
EXECUTE_PROCESS(
COMMAND ${PYTHON_EXECUTABLE} ${UNZIP_SCRIPT} ${eggs}
WORKING_DIRECTORY ...
)
You might want to provide an unzip_all_eggs.cmake.in template including
SET(PYTHON_EXECUTABLE @PYTHON_EXECUTABLE@)
SET(UNZIP_SCRIPT @UNZIP_SCRIPT@)
use CONFIGURE_FILE(unzip_all_eggs.cmake.in unzip_all_eggs.cmake @ONLY)
to generate the actual unzip_all_eggs.cmake after searching Python and
your script, and specify -P ${CMAKE_BINARY_DIR}/unzip_all_eggs.cmake.
Thanks, this is really nice in general and I might use it in the future.
The problem is that in this specific case it doesn't buy me much and
adds complexity, because
I would still have only one target unzipping all the eggs.
It would be nice to be able to generate N target 1 for each egg.
In order to define one target per egg, you'd need to know the eggs at
configuration time since you cannot define targets at build time. So,
gathering the eggs with a custom target/command will not work. As an
alternative, you might gather the eggs at configuration time with a
FILE(GLOB ...) command, loop over the resulting list and define one
target per item. However, your Makefiles would not be aware of any
changes among the eggs - additions, removals, renamings - and you
would need to remember to reconfigure your project by hand if you
don't want to miss any changes. That's somewhat error-prone and
means relinquishing one of CMake's benefits.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Shared intermediary files
On 02/20/2012 10:07 PM, Kevin Schmidt wrote: Hello, I'm in the process of converting over a large, monolithic tree with many libraries from a custom build solution over to cmake. So far, we've loved it. I am wondering about others' solutions to a problem we have encountered. We have more than a few cases of generated source files - for example, Qt moc files. These all get dumped into CMAKE_CURRENT_BINARY_DIR. Now, the libraries we have build both static shared, and have the same source files. In Visual Studio, this generates two projects in the solution. It seems that these do not share dependencies. Occasionally, this means that both libraries try to write to the generated source file at the same time, which generates a (false) build failure. What do others do? Am I misunderstanding something? Kevin How do you generate the source files? Supposedly, you're using custom commands, right? At least, QT4_WRAP_CPP() does. If so, you probably walk right into a quite common trap - from the documentation of ADD_CUSTOM_COMMAND(): Do not list the output in more than one independent target that may build in parallel or the two instances of the rule may conflict (instead use add_custom_target to drive the command and make the other targets depend on that one). If your issue isn't related to custom commands, could you provide more detailed information how you generate the source files in question? Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] passing arguments to the final make
On 02/22/2012 09:18 PM, Michael Hertling wrote:
On 02/22/2012 06:56 PM, Andrea Crotti wrote:
On 02/22/2012 05:32 PM, Andrea Crotti wrote:
Ah that's nice thanks, I'm not sure though that I can rely on being=
2.8 always,
and that's probably a requirement, right?
I tried what you suggested and with this:
add_custom_target(dev_no_run
COMMAND ${PYTHON_EXECUTABLE} ${DEV_MAIN} -w ${WORKSPACE}
${APPLICATION} --develop_only -l info
COMMAND ${PYTHON_EXECUTABLE} \${SCRIPT}
)
I get this in the Makefile:
CMakeFiles/dev_no_run:
/usr/bin/python
/home/andrea/git_projs/PSI_Hamburg/utils/utils/bin/dev_main.py -w
/home/andrea/git_projs
/home/andrea/git_projs/Minimum_Drag/airbus.application.minimum_drag
--develop_only -l info
/usr/bin/python ${SCRIPT}
which is probably not what I want, because for a Makefile it should be
$(SCRIPT), right?
In Makefiles, $(SCRIPT) and ${SCRIPT} are equivalent, see [1]. However,
parentheses can have a special meaning w.r.t. a library's object files,
and $() is primarily associated with the shell's command substitution.
Thus, I personally prefer ${} for dereferencing macros in Makefiles
since it's quite unambiguous.
Regards,
Michael
Ah good thanks, I have to check what happened then tomorrow because it
didn't
work properly anyway...
And another thing, is it actually \${SCRIPT} a portable solution that
works on all the generators?
--
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] delayed target
On 02/22/2012 09:37 PM, Michael Hertling wrote: In order to define one target per egg, you'd need to know the eggs at configuration time since you cannot define targets at build time. So, gathering the eggs with a custom target/command will not work. As an alternative, you might gather the eggs at configuration time with a FILE(GLOB ...) command, loop over the resulting list and define one target per item. However, your Makefiles would not be aware of any changes among the eggs - additions, removals, renamings - and you would need to remember to reconfigure your project by hand if you don't want to miss any changes. That's somewhat error-prone and means relinquishing one of CMake's benefits. Regards, Michael - Yes sure when there are changes in that sense we need to reconfigure, but it's really not a big deal in our case because it won't almost never happen, and anyway I don't really have any other choice if I want to use the parallelization provided by make -j. -- 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] lexical scoping ... back to the future !
Hi François, Would the use of function be helpful ? See http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:function and http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:set If PARENT_SCOPE is present, the variable will be set in the scope above the current scope. Each new directory or function creates a new scope. This command will set the value of a variable into the parent directory or calling function (whichever is applicable to the case at hand). I created a small example showing that variable set within a function don't interfere with the parent scope if not explicitly required. git clone git://gist.github.com/136.git cmake -P 136/cmake-illustrate-function-scope.cmake Hth Jc On Wed, Feb 22, 2012 at 7:07 PM, François Mauger mau...@lpccaen.in2p3.frwrote: Hi CMakers, In november 2007, there was a long thread titled lexical scoping. The discussion was really interesting and was suggesting that some local scoping features for variables could be implemented in CMake... particularly from macros, which are probably the practical case that causes most issues when users implement several nested levels of macro invocations with many intermediate temporary variables that unfortunately aggregate in the global scope. It is really easy to face such problem in a rather large project driven with Cmake (a dependency driver invoking the find_package command in a foreach loop must be done from a macro AFAIK). Unless I missed something in the jungle of CMake threads and doc, I'm afraid I was not able to find some satisfactory solution other than hacks (using very long variable names to emulate some pseudo local scopes). this is tedious and bug prone. Browsing the last 4 years of archives and some additionnal docs, I was not able to find a single trace of such new feature : implementing local scoping in CMake (whatever local scoping could rationally mean). What is the current situation on users' side ? Is there any pressure for local scoping ? Maybe too few people ask for it so CMake developpers do not consider it as a priority... or no clear definition of local scoping has been patterned ? more what is the view of the CMake devel team ? do they consider this idea as a good one or not ? Thanks a lot for hints and advices. Best regards frc -- François Mauger LPC Caen-CNRS/IN2P3-UCBN-ENSICAEN Département de Physique -- Université de Caen Basse-Normandie -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake -- +1 919 869 8849 -- 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] delayed target
On 02/22/2012 11:55 PM, Andrea Crotti wrote: On 02/22/2012 09:37 PM, Michael Hertling wrote: In order to define one target per egg, you'd need to know the eggs at configuration time since you cannot define targets at build time. So, gathering the eggs with a custom target/command will not work. As an alternative, you might gather the eggs at configuration time with a FILE(GLOB ...) command, loop over the resulting list and define one target per item. However, your Makefiles would not be aware of any changes among the eggs - additions, removals, renamings - and you would need to remember to reconfigure your project by hand if you don't want to miss any changes. That's somewhat error-prone and means relinquishing one of CMake's benefits. Regards, Michael - Yes sure when there are changes in that sense we need to reconfigure, but it's really not a big deal in our case because it won't almost never happen, and anyway I don't really have any other choice if I want to use the parallelization provided by make -j. There is a possibility to dynamically reconfigure/rebuild the project without an intermediate manual step and in a way that you'll have one target per egg, but that approach is disadvantageous in other regards and possibly won't work with generators other than the Makefiles ones. IMO, if you really need one target per egg, you should gather them at configure time and accept the need to reconfigure the project by hand when necessary. If one target per egg isn't a must-do, gather them at build time and use a script - CMake, shell, whatever - to unzip them; this can be done well in parallel also. Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] passing arguments to the final make
On 02/23/2012 12:04 AM, John Drescher wrote:
And another thing, is it actually \${SCRIPT} a portable solution that works
on all the generators?
This is not about generators but about what shell you are running
cmake from. For example that would not work on windows since the
command prompt has a different syntax for variables.
The point is that ${SCRIPT} is substituted in the Makefile by
(1) a macro specified on the command line
(2) a macro specified in the Makefile
(3) an environment variable
in that order, or with (2) and (3) reversed if Make is invoked with the
-e switch. When the Makefile's command lines are passed to the shell,
the substitution has already taken place, so it should also work with
the Windows command prompt. However, one needs a Make program, i.e. a
parameterization of this kind probably doesn't work with non-Makefile
generators. Even with Makefiles, there are subtle pitfalls: If a line
SCRIPT = ... happens to appear somewhere in the Makefiles, invoking
Make as make SCRIPT=... will overwrite it, most certainly resulting
in surprising and undesired behaviour. Personally, I'd advise against
using this method without explicit support by the Makefile generator.
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.7-2802-g0a8634a
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 0a8634a82fd914adb1d2c3907438c1cfc97b7b43 (commit)
via 0110262a2d93da0911f7439ac5fba4e18b29757e (commit)
from 4789bae0797b09feb300dcd97f1ca362bbf35ff7 (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=0a8634a82fd914adb1d2c3907438c1cfc97b7b43
commit 0a8634a82fd914adb1d2c3907438c1cfc97b7b43
Merge: 4789bae 0110262
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Feb 22 11:51:22 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Feb 22 11:51:22 2012 -0500
Merge topic 'simplify-findopenmp' into next
0110262 FindOpenMP: simplify check for enabled languages
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0110262a2d93da0911f7439ac5fba4e18b29757e
commit 0110262a2d93da0911f7439ac5fba4e18b29757e
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Feb 22 17:47:52 2012 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Wed Feb 22 17:47:52 2012 +0100
FindOpenMP: simplify check for enabled languages
diff --git a/Modules/FindOpenMP.cmake b/Modules/FindOpenMP.cmake
index e1af15e..b96a2ec 100644
--- a/Modules/FindOpenMP.cmake
+++ b/Modules/FindOpenMP.cmake
@@ -25,11 +25,6 @@
# (To distribute this file outside of CMake, substitute the full
# License text for the above reference.)
-get_property(_ENABLED_LANGUAGES GLOBAL PROPERTY ENABLED_LANGUAGES)
-list(FIND _ENABLED_LANGUAGES C _HAVE_LANGUAGE_C)
-list(FIND _ENABLED_LANGUAGES CXX _HAVE_LANGUAGE_CXX)
-unset(_ENABLED_LANGUAGES)
-
set(_OPENMP_REQUIRED_VARS)
function(_OPENMP_FLAG_CANDIDATES LANG)
@@ -93,7 +88,7 @@ int main() {
)
# check c compiler
-if(NOT _HAVE_LANGUAGE_C EQUAL -1)
+if(CMAKE_C_COMPILER_LOADED)
# if these are set then do not try to find them again,
# by avoiding any try_compiles for the flags
if(OpenMP_C_FLAGS)
@@ -124,7 +119,7 @@ if(NOT _HAVE_LANGUAGE_C EQUAL -1)
endif()
# check cxx compiler
-if(NOT _HAVE_LANGUAGE_CXX EQUAL -1)
+if(CMAKE_CXX_COMPILER_LOADED)
# if these are set then do not try to find them again,
# by avoiding any try_compiles for the flags
if(OpenMP_CXX_FLAGS)
@@ -158,9 +153,6 @@ if(NOT _HAVE_LANGUAGE_CXX EQUAL -1)
unset(OpenMP_CXX_TEST_SOURCE)
endif()
-unset(_HAVE_LANGUAGE_C)
-unset(_HAVE_LANGUAGE_CXX)
-
if(_OPENMP_REQUIRED_VARS)
include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
---
Summary of changes:
Modules/FindOpenMP.cmake | 12 ++--
1 files changed, 2 insertions(+), 10 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.7-2818-g17e0e47
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 17e0e47fc2726ae19b44d13d3e74e9617e8906f7 (commit)
via 9d548711901998c0b4d2b9003f3a8977e5aa4f2f (commit)
via e5eda9edff3f859e6180631e14d44f7aa7d50d69 (commit)
via ae41323bda6815f9198b3f14a0ab3bc4aac84412 (commit)
from 52d9d34ad13bf52ec3ce790823c1f7460a600e62 (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=17e0e47fc2726ae19b44d13d3e74e9617e8906f7
commit 17e0e47fc2726ae19b44d13d3e74e9617e8906f7
Merge: 52d9d34 9d54871
Author: David Cole david.c...@kitware.com
AuthorDate: Wed Feb 22 16:33:55 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Feb 22 16:33:55 2012 -0500
Merge topic 'ninja-generator' into next
9d54871 CMake: Adapt Ninja generator for per-target include dirs
e5eda9e Merge branch 'target-include-directories' into ninja-generator
ae41323 windows msvc: create for each target a .pdb file
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9d548711901998c0b4d2b9003f3a8977e5aa4f2f
commit 9d548711901998c0b4d2b9003f3a8977e5aa4f2f
Author: David Cole david.c...@kitware.com
AuthorDate: Wed Feb 22 16:31:00 2012 -0500
Commit: David Cole david.c...@kitware.com
CommitDate: Wed Feb 22 16:31:00 2012 -0500
CMake: Adapt Ninja generator for per-target include dirs
The confluence of the ninja-generator and target-include-directories
branches conspired to produce a nice little compiler error when
they were both merged into 'next'...
Yay for Continuous dashboards!
diff --git a/Source/cmNinjaTargetGenerator.cxx
b/Source/cmNinjaTargetGenerator.cxx
index 7b1c7d9..c776fcf 100644
--- a/Source/cmNinjaTargetGenerator.cxx
+++ b/Source/cmNinjaTargetGenerator.cxx
@@ -145,8 +145,11 @@ cmNinjaTargetGenerator::ComputeFlagsForObject(cmSourceFile
*source,
// TODO: Handle response file.
// Add include directory flags.
{
+ std::vectorstd::string includes;
+ this-LocalGenerator-GetIncludeDirectories(includes, this-Target,
+ language.c_str());
std::string includeFlags =
-this-LocalGenerator-GetIncludeFlags(language.c_str(), false);
+this-LocalGenerator-GetIncludeFlags(includes, language.c_str(), false);
this-LocalGenerator-AppendFlags(flags, includeFlags.c_str());
}
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e5eda9edff3f859e6180631e14d44f7aa7d50d69
commit e5eda9edff3f859e6180631e14d44f7aa7d50d69
Merge: ae41323 8233636
Author: David Cole david.c...@kitware.com
AuthorDate: Wed Feb 22 16:21:48 2012 -0500
Commit: David Cole david.c...@kitware.com
CommitDate: Wed Feb 22 16:21:48 2012 -0500
Merge branch 'target-include-directories' into ninja-generator
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ae41323bda6815f9198b3f14a0ab3bc4aac84412
commit ae41323bda6815f9198b3f14a0ab3bc4aac84412
Author: Peter Kuemmel syntheti...@gmx.net
AuthorDate: Tue Feb 21 21:18:05 2012 +0100
Commit: Peter Kuemmel syntheti...@gmx.net
CommitDate: Tue Feb 21 21:18:05 2012 +0100
windows msvc: create for each target a .pdb file
diff --git a/Source/cmNinjaNormalTargetGenerator.cxx
b/Source/cmNinjaNormalTargetGenerator.cxx
index 9294a01..6e08bca 100644
--- a/Source/cmNinjaNormalTargetGenerator.cxx
+++ b/Source/cmNinjaNormalTargetGenerator.cxx
@@ -136,6 +136,7 @@ cmNinjaNormalTargetGenerator
vars.Target = $out;
vars.TargetSOName = $SONAME;
vars.TargetInstallNameDir = $INSTALLNAME_DIR;
+vars.TargetPDB = $TARGET_PDB;
// Setup the target version.
std::string targetVersionMajor;
@@ -361,6 +362,8 @@ void cmNinjaNormalTargetGenerator::WriteLinkStatement()
targetOutputImplib.c_str(), cmLocalGenerator::SHELL);
}
+ vars[TARGET_PDB] = this-GetTargetPDB();
+
std::vectorcmCustomCommand *cmdLists[3] = {
this-GetTarget()-GetPreBuildCommands(),
this-GetTarget()-GetPreLinkCommands(),
diff --git a/Source/cmNinjaTargetGenerator.cxx
b/Source/cmNinjaTargetGenerator.cxx
index 8a563b6..7b1c7d9 100644
--- a/Source/cmNinjaTargetGenerator.cxx
+++ b/Source/cmNinjaTargetGenerator.cxx
@@ -270,6 +270,23 @@ std::string cmNinjaTargetGenerator::GetTargetName() const
return this-Target-GetName();
}
+std::string cmNinjaTargetGenerator::GetTargetPDB() const
+{
+ std::string targetFullPathPDB;
+ if(this-Target-GetType() == cmTarget::EXECUTABLE ||
+ this-Target-GetType() == cmTarget::STATIC_LIBRARY ||
+ this-Target-GetType() == cmTarget::SHARED_LIBRARY ||
+ this-Target-GetType() == cmTarget::MODULE_LIBRARY)
+{
+targetFullPathPDB =
[Cmake-commits] CMake branch, next, updated. v2.8.7-2822-g506a26e
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 506a26e175a145d47b6af38f0b4c12b329d55724 (commit)
via f66e735de393c25408d9e955aa8f27c9611ac245 (commit)
from 4ec73c5a4ac305a2faccc45862e6df18f7404cae (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=506a26e175a145d47b6af38f0b4c12b329d55724
commit 506a26e175a145d47b6af38f0b4c12b329d55724
Merge: 4ec73c5 f66e735
Author: David Cole david.c...@kitware.com
AuthorDate: Wed Feb 22 17:13:40 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Feb 22 17:13:40 2012 -0500
Merge topic 'target-include-directories' into next
f66e735 Fix compiler warning reported on older Borland dashboard.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f66e735de393c25408d9e955aa8f27c9611ac245
commit f66e735de393c25408d9e955aa8f27c9611ac245
Author: David Cole david.c...@kitware.com
AuthorDate: Wed Feb 22 17:12:11 2012 -0500
Commit: David Cole david.c...@kitware.com
CommitDate: Wed Feb 22 17:12:11 2012 -0500
Fix compiler warning reported on older Borland dashboard.
Avoid assignment inside the if.
diff --git a/Source/cmDepends.cxx b/Source/cmDepends.cxx
index b511f65..9296d4c 100644
--- a/Source/cmDepends.cxx
+++ b/Source/cmDepends.cxx
@@ -266,7 +266,8 @@ void cmDepends::SetIncludePathFromLanguage(const char* lang)
includePathVar += lang;
includePathVar += _TARGET_INCLUDE_PATH;
cmMakefile* mf = this-LocalGenerator-GetMakefile();
- if(includePath = mf-GetDefinition(includePathVar.c_str()))
+ includePath = mf-GetDefinition(includePathVar.c_str());
+ if(includePath)
{
cmSystemTools::ExpandListArgument(includePath, this-IncludePath);
}
@@ -276,7 +277,8 @@ void cmDepends::SetIncludePathFromLanguage(const char* lang)
includePathVar = CMAKE_;
includePathVar += lang;
includePathVar += _INCLUDE_PATH;
-if(includePath = mf-GetDefinition(includePathVar.c_str()))
+includePath = mf-GetDefinition(includePathVar.c_str());
+if(includePath)
{
cmSystemTools::ExpandListArgument(includePath, this-IncludePath);
}
---
Summary of changes:
Source/cmDepends.cxx |6 --
1 files changed, 4 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.7-450-ge8e964f
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 e8e964f675dc2475e871a13bb5dae99ef7a40201 (commit) from 6a1c5a356911d3b75e60ecad86d7538e6de888f9 (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=e8e964f675dc2475e871a13bb5dae99ef7a40201 commit e8e964f675dc2475e871a13bb5dae99ef7a40201 Author: KWSys Robot kwro...@kitware.com AuthorDate: Thu Feb 23 00:01:03 2012 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Thu Feb 23 00:05:06 2012 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index baf15ad..33c8c08 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2012) SET(KWSYS_DATE_STAMP_MONTH 02) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 22) +SET(KWSYS_DATE_STAMP_DAY 23) --- 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
