[cmake-developers] [CMake 0012946]: Lack of ability to specify location of SSL CA bundle at compile time
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=12946
==
Reported By:Artur Kedzierski
Assigned To:
==
Project:CMake
Issue ID: 12946
Category: CMake
Reproducibility:always
Severity: minor
Priority: high
Status: new
==
Date Submitted: 2012-02-08 13:23 EST
Last Modified: 2012-02-08 13:23 EST
==
Summary:Lack of ability to specify location of SSL CA bundle
at compile time
Description:
Currently, there is no way of specifying location of SSL CA bundle at compile
time. Source code has to be changed first. Addition of the following code to
Utilities/cmcurl/CMakeLists.txt would fix the problem:
SET(CURL_CA_BUNDLE CACHE FILEPATH Path to SSL CA Certificate Bundle)
MARK_AS_ADVANCED(CURL_CA_BUNDLE)
IF(CURL_CA_BUNDLE)
ADD_DEFINITIONS(-DCURL_CA_BUNDLE=${CURL_CA_BUNDLE})
ENDIF(CURL_CA_BUNDLE)
Steps to Reproduce:
1. Compile CMake with SSL support on Windows using built-in curl
2. Run CTest that submits to CDash
Step 2 will fail as it will not find SSL CA bundle to verify website's SSL
certificate.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-02-08 13:23 Artur KedzierskiNew Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Topic branches in limbo on the stage?
The stage is intended only for topics that are imminently going to be merged to 'next'... The following CMake topic branches have been on the stage for quite some time without being merged to 'next': UseEnabledLanguagesForDirectoryInformationFileIncludePath | master=0 next=0 qt4-deploy | master=0 next=0 HandleTargetsInCMakeRequiredLibraries | master=0 next=0 CPackNSIS-fixIgnore-INCLUDE_TOPLEVEL | master=0 next=0 qt4-deploy-test | master=0 next=0 findblas-bugs | master=0 next=0 If it's ready to be tested on the dashboard machines, then please merge it to 'next'. If not, and you are the developer responsible for one of these (author, committer, reviewer) please coordinate with whomever you need to in order to get these things into 'next' soon. The 'cc' line here are authors and committers of the tips of these branches. Or... if you've abandoned the work, or you do not have time or do not plan to work on this within the next two weeks, please just grab a local copy, and then delete the topic from the stage: git fetch stage git checkout -b topicname stage/topicname git push stage :topicname (Of course, replacing topicname with the actual name of the topic you are deleting.) Thanks -- that will make our weekly merge sessions easier to do when we don't have to deal with this handful of noise that's not ready yet. Please consider using github or some other free online git hosting facility for sharing branches with others when they are not yet ready for next. Eventually, we'll get a gerrit instance to host CMake for us so that we can review changes in gerrit and avoid this sort of thing by default. 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] Topic branches in limbo on the stage?
2012/2/8 David Cole david.c...@kitware.com: The stage is intended only for topics that are imminently going to be merged to 'next'... The following CMake topic branches have been on the stage for quite some time without being merged to 'next': CPackNSIS-fixIgnore-INCLUDE_TOPLEVEL | master=0 next=0 If it's ready to be tested on the dashboard machines, then please merge it to 'next'. Just done for this one which is mine. It fixes bug #12935. Now for have been on the stage for quite some time You guys will be reaching light speed soon enough; You mail: 2012/2/8 David Cole david.c...@kitware.com: My unmerged commit: commit 6a74eb1d36b079fe6b566244a636ac1e43303aa6 Author: Eric NOULARD eric.noul...@gmail.com Date: Sun Feb 5 13:13:48 2012 +0100 3 days!! Just kidding but... Thanks -- that will make our weekly merge sessions easier to do when we don't have to deal with this handful of noise that's not ready yet. OK. Please consider using github or some other free online git hosting facility for sharing branches with others when they are not yet ready for next. Noted too. Eventually, we'll get a gerrit instance to host CMake for us so that we can review changes in gerrit and avoid this sort of thing by default. Would be nice. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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] [CTest] request information on usage of CTEST_CUSTOM_COVERAGE_EXCLUDE and CTestCustom.cmake
I would like to exclude third party header files from the coverage
output. We're using ctest, cmake (version 2.8.5) and cdash, all on
Linux. The archive layout is as follows:
/
/Code/
/Code/Application/
/Code/Application/src/
/Code/Third-Party/
/Code/Third-Party/boost/
/Code/Third-Party/boost/boost-1-47-0/
/Code/Third-Party/boost/boost-1-47-0/include/
/Code/Third-Party/boost/boost-1-47-0/lib/
/Code/Build/
The /Code/Build directory contains a script that is called using ctest
-S /Code/Build/buildscript. The /Code directory contains a
CMakeLists.txt, a CTestConfig.cmake and a CTestCustom.cmake file.
The CMakeLists.txt file in /Code/Application/src/ uses
CONFIGURE_FILE(${CMAKE_SOURCE_DIR}/CTestCustom.cmake
${CMAKE_BINARY_DIR}/CTestCustom.cmake COPYONLY) to copy the
CTestCustom.cmake file to the toplevel of the builddirectory. The file
does indeed end up in the toplevel builddirectory.
The CTestCustom.cmake file is as follows:
SET(CTEST_CUSTOM_COVERAGE_EXCLUDE
${CTEST_CUSTOM_COVERAGE_EXCLUDE}
/Code/Third-Party/*
)
I compile all code with the following flags:
SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -g -O0 -fprofile-arcs -ftest-coverage)
Although coverage does get sent to the CDash dashboard, the results
contain more than I would like to see. I would like to exclude the .hpp
files from the /Code/Third-Party/boost/boost-1-47-0/include/ directory
from the dashboard.
My questions:
-- Is the /Code/Third-Party/* expression recursive, or do I need to add
the full path to the include directory of boost?
-- Does the '/' at the front of the path mean the CMAKE_SOURCE_DIR?
Any advice or pointers to information on how to achieve the exclusion
would be greatly appreciated.
With kind regards,
Micha Hergarden
--
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] [Java] - Adding manifest information to a jar file
On Tuesday 07 February 2012 13:01:49 David Cole wrote:
2012/2/7 Nicolas Desprès nicolas.desp...@gmail.com:
On Sat, Dec 10, 2011 at 3:46 PM, Andreas Schneider a...@cryptomilk.org
wrote:
On Saturday 29 October 2011 23:34:50 Frank Glinka wrote:
Hi,
Hi,
Hi,
I am happy about the recently improved Java support within cmake.
Thanks! Anyhow, I have a small point which should be easy to improve and
which would deliver quite some usability, in my opinion.
The current syntax for building and packaging Java files is:
add_jar(${TARGETNAME} ${SOURCE_FILES} ${RESOURCE_FILES})
This has some drawbacks:
1) No executable jar can be created with that method. It seems there is
already some effort on that issue as:
https://github.com/viandfraich/CMake/commit/36b223e34f5d48339da39e833a2f
5e7d f2866e87
I don't like the way how it has been added here. I think it should be an
optional vairable you set before like the others. Please open a feature
request in the bug tracker. Patches are welcome.
Here is a proposal:
https://github.com/polrop/CMake/commits/java-executable-jar
2) A jar file can be annotated with a lot of more important information,
e.g., version information, scope, main-class (would also catch the first
issue), etc. This information is normally passed as a property/manifest
file when calling the jar packager. Currently, the UseJava.cmake
module creates the following command within 'add_jar':
jar cf ${TARGETNAME} ${CLASS_FILES} ${RESOURCE_FILES}
The following would solve my (and I guess many others') use cases:
jar cmf ${TARGETNAME} MyManifest.mf ${CLASS_FILES} ${RESOURCE_FILES}
Should be an optional option and should be done like the other options.
set(CMAKE_JAVA_MANIFEST mymanifest.mf)
add_jar(foo foo.java)
I don't have any patch for this issue yet. Maybe in the future.
An optional command to add_jar would be desirable which allows to
provide an optional manifest file. If provided, the later syntax should
be used for calling the 'jar' tool.
Will there be progress towards supporting manifest information anytime
soon within cmake?
Open a feature request in the bugtracker.
Please tell me what you think about the proposal.
Regards,
--
Nicolas Desprès
--
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 proposed commits (3 of them, right?) at
https://github.com/polrop/CMake/commits/java-executable-jar look
reasonable to me.
Any objections from people who care about Java to getting these into
CMake 'next' ...?
Hi,
David they look good to me. Should I push them to staging or do you want to do
it?
Cheers,
-- andreas
--
Andreas Schneider GPG-ID: F33E3FC6
www.cryptomilk.orga...@cryptomilk.org
--
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] [CTest] request information on usage of CTEST_CUSTOM_COVERAGE_EXCLUDE and CTestCustom.cmake
I would like to exclude third party header files from the coverage
output. We're using ctest, cmake (version 2.8.5) and cdash, all on
Linux. The archive layout is as follows:
/
/Code/
/Code/Application/
/Code/Application/src/
/Code/Third-Party/
/Code/Third-Party/boost/
/Code/Third-Party/boost/boost-1-47-0/
/Code/Third-Party/boost/boost-1-47-0/include/
/Code/Third-Party/boost/boost-1-47-0/lib/
/Code/Build/
The /Code/Build directory contains a script that is called using ctest
-S /Code/Build/buildscript. The /Code directory contains a
CMakeLists.txt, a CTestConfig.cmake and a CTestCustom.cmake file.
The CMakeLists.txt file in /Code/Application/src/ uses
CONFIGURE_FILE(${CMAKE_SOURCE_DIR}/CTestCustom.cmake
${CMAKE_BINARY_DIR}/CTestCustom.cmake COPYONLY) to copy the
CTestCustom.cmake file to the toplevel of the builddirectory. The file
does indeed end up in the toplevel builddirectory.
The CTestCustom.cmake file is as follows:
SET(CTEST_CUSTOM_COVERAGE_EXCLUDE
${CTEST_CUSTOM_COVERAGE_EXCLUDE}
/Code/Third-Party/*
)
I compile all code with the following flags:
SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -g -O0 -fprofile-arcs
-ftest-coverage)
Although coverage does get sent to the CDash dashboard, the results
contain more than I would like to see. I would like to exclude the .hpp
files from the /Code/Third-Party/boost/boost-1-47-0/include/ directory
from the dashboard.
My questions:
-- Is the /Code/Third-Party/* expression recursive, or do I need to add
the full path to the include directory of boost?
You don't need the * at all, it will just match anywhere in the path. And
since it's a regular expression I think your intention was /.* anyway.
-- Does the '/' at the front of the path mean the CMAKE_SOURCE_DIR?
It just means a directory, so it wont match /FunnyCode/Third-Party.
Any advice or pointers to information on how to achieve the exclusion
would be greatly appreciated.
You need to put the file in CMAKE_BINARY_DIR, otherwise it will get ignored.
CONFIGURE_FILE(${CMAKE_SOURCE_DIR}/CTestCustom.cmake
${CMAKE_BINARY_DIR}/CTestCustom.cmake @ONLY)
Eike
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [CTest] request information on usage of CTEST_CUSTOM_COVERAGE_EXCLUDE and CTestCustom.cmake
On 02/08/2012 12:00 PM, Rolf Eike Beer wrote:
I would like to exclude third party header files from the coverage
output. We're using ctest, cmake (version 2.8.5) and cdash, all on
Linux. The archive layout is as follows:
/
/Code/
/Code/Application/
/Code/Application/src/
/Code/Third-Party/
/Code/Third-Party/boost/
/Code/Third-Party/boost/boost-1-47-0/
/Code/Third-Party/boost/boost-1-47-0/include/
/Code/Third-Party/boost/boost-1-47-0/lib/
/Code/Build/
The /Code/Build directory contains a script that is called using ctest
-S /Code/Build/buildscript. The /Code directory contains a
CMakeLists.txt, a CTestConfig.cmake and a CTestCustom.cmake file.
The CMakeLists.txt file in /Code/Application/src/ uses
CONFIGURE_FILE(${CMAKE_SOURCE_DIR}/CTestCustom.cmake
${CMAKE_BINARY_DIR}/CTestCustom.cmake COPYONLY) to copy the
CTestCustom.cmake file to the toplevel of the builddirectory. The file
does indeed end up in the toplevel builddirectory.
The CTestCustom.cmake file is as follows:
SET(CTEST_CUSTOM_COVERAGE_EXCLUDE
${CTEST_CUSTOM_COVERAGE_EXCLUDE}
/Code/Third-Party/*
)
I compile all code with the following flags:
SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -g -O0 -fprofile-arcs
-ftest-coverage)
Although coverage does get sent to the CDash dashboard, the results
contain more than I would like to see. I would like to exclude the .hpp
files from the /Code/Third-Party/boost/boost-1-47-0/include/ directory
from the dashboard.
My questions:
-- Is the /Code/Third-Party/* expression recursive, or do I need to add
the full path to the include directory of boost?
You don't need the * at all, it will just match anywhere in the path. And
since it's a regular expression I think your intention was /.* anyway.
-- Does the '/' at the front of the path mean the CMAKE_SOURCE_DIR?
It just means a directory, so it wont match /FunnyCode/Third-Party.
Any advice or pointers to information on how to achieve the exclusion
would be greatly appreciated.
You need to put the file in CMAKE_BINARY_DIR, otherwise it will get ignored.
CONFIGURE_FILE(${CMAKE_SOURCE_DIR}/CTestCustom.cmake
${CMAKE_BINARY_DIR}/CTestCustom.cmake @ONLY)
Eike
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Thank you for your quick reply. I will try the regex changes you
mentioned. It turns out I had forgotten to explicitly read the
CTestCustom.cmake script in the ctest -S script (
ctest_read_custom_files(${CTEST_BINARY_DIRECTORY}) ), so that caused
the file to not be parsed at all.
Micha
--
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] Compile CMakeCache.txt into shared library
Dear Cmake List, we would like to include a CmakeCache.txt file into our shared library. The reason is, that we would like to know what CMake options were used when compiling the library in case we have only the binary. Has anyone done something like this before and can give me some pointers? Thanks for any advice Valentin Note: I am not subscribed to this list, so pleae cc me in your response. -- Valentin Hänel Scientific Software Developer Blue Brain Project http://bluebrain.epfl.ch/ -- 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] Compile CMakeCache.txt into shared library
Dear Cmake List, we would like to include a CmakeCache.txt file into our shared library. The reason is, that we would like to know what CMake options were used when compiling the library in case we have only the binary. Has anyone done something like this before and can give me some pointers? Thanks for any advice Valentin -- Valentin Hänel Scientific Software Developer Blue Brain Project http://bluebrain.epfl.ch/ -- 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] Compile CMakeCache.txt into shared library
Hi,
I'm not sure if I understand you correctly, but I would guess that in most
cases you don't need to know _all_ cmake cache variables at runtime.
If you really just need to know some specific variables, you would be much
better off using a generated header file. See the documentation for
configure_file
for details on this.
In short, you'd make a headerfile config.h.in with lines like this:
#cmakedefine @my_magic_variable@
And in cmakeLists:
configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/config.h.in
${CMAKE_CURRENT_BINARY_DIR}/config.h )
Afterwards, you can include config.h in your shared library and you can use the
value there...
HTH,
Johannes
On Wednesday 08 February 2012, 14:34:00, Hänel Nikolaus Valentin wrote:
Dear Cmake List,
we would like to include a CmakeCache.txt file into our shared
library. The reason is, that we would like to know what CMake options
were used when compiling the library in case we have only the binary.
Has anyone done something like this before and can give me some
pointers?
Thanks for any advice
Valentin
--
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] Compile CMakeCache.txt into shared library
* Johannes Zarl johannes.z...@jku.at [120208]:
Hi,
I'm not sure if I understand you correctly, but I would guess that in most
cases you don't need to know _all_ cmake cache variables at runtime.
If you really just need to know some specific variables, you would be much
better off using a generated header file. See the documentation for
configure_file
for details on this.
In short, you'd make a headerfile config.h.in with lines like this:
#cmakedefine @my_magic_variable@
And in cmakeLists:
configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/config.h.in
${CMAKE_CURRENT_BINARY_DIR}/config.h )
Afterwards, you can include config.h in your shared library and you can use
the
value there...
Ah, yes. Thats great! Thanks!
V-
--
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] [Java] - Adding manifest information to a jar file
On Wed, Feb 8, 2012 at 3:20 AM, Andreas Schneider a...@cryptomilk.orgwrote:
On Tuesday 07 February 2012 13:01:49 David Cole wrote:
2012/2/7 Nicolas Desprès nicolas.desp...@gmail.com:
On Sat, Dec 10, 2011 at 3:46 PM, Andreas Schneider a...@cryptomilk.org
wrote:
On Saturday 29 October 2011 23:34:50 Frank Glinka wrote:
Hi,
Hi,
Hi,
I am happy about the recently improved Java support within cmake.
Thanks! Anyhow, I have a small point which should be easy to improve
and
which would deliver quite some usability, in my opinion.
The current syntax for building and packaging Java files is:
add_jar(${TARGETNAME} ${SOURCE_FILES} ${RESOURCE_FILES})
This has some drawbacks:
1) No executable jar can be created with that method. It seems there
is
already some effort on that issue as:
https://github.com/viandfraich/CMake/commit/36b223e34f5d48339da39e833a2f
5e7d f2866e87
I don't like the way how it has been added here. I think it should be
an
optional vairable you set before like the others. Please open a
feature
request in the bug tracker. Patches are welcome.
Here is a proposal:
https://github.com/polrop/CMake/commits/java-executable-jar
2) A jar file can be annotated with a lot of more important
information,
e.g., version information, scope, main-class (would also catch the
first
issue), etc. This information is normally passed as a
property/manifest
file when calling the jar packager. Currently, the UseJava.cmake
module creates the following command within 'add_jar':
jar cf ${TARGETNAME} ${CLASS_FILES} ${RESOURCE_FILES}
The following would solve my (and I guess many others') use cases:
jar cmf ${TARGETNAME} MyManifest.mf ${CLASS_FILES}
${RESOURCE_FILES}
Should be an optional option and should be done like the other
options.
set(CMAKE_JAVA_MANIFEST mymanifest.mf)
add_jar(foo foo.java)
I don't have any patch for this issue yet. Maybe in the future.
An optional command to add_jar would be desirable which allows to
provide an optional manifest file. If provided, the later syntax
should
be used for calling the 'jar' tool.
Will there be progress towards supporting manifest information
anytime
soon within cmake?
Open a feature request in the bugtracker.
Please tell me what you think about the proposal.
Regards,
--
Nicolas Desprès
--
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 proposed commits (3 of them, right?) at
https://github.com/polrop/CMake/commits/java-executable-jar look
reasonable to me.
Any objections from people who care about Java to getting these into
CMake 'next' ...?
Hi,
David they look good to me. Should I push them to staging or do you want
to do
it?
Cheers,
-- andreas
--
Andreas Schneider GPG-ID: F33E3FC6
www.cryptomilk.orga...@cryptomilk.org
I would love it if you would push them to the stage and merge to 'next'...
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target
I had a hard time following these questions. It sounds like you're asking the following: 1) Can you set things up so that F7 does a full build and then automatically does the INSTALL target build? 2) Can you set things up so that you can build a sub project and have it install just that sub project automatically? Assuming those are your questions, I'm guessing there isn't a good way to do that automatically. Barring any better suggestions from more experienced CMaketeers, I would probably look into creating a function that adds a post build step to a project which will perform the installation of the project. Then doing a build all would cause each project to individually build and install, and building a single subproject would cause that subproject to build and install (thus solving 1 and 2 together). That doesn't seem ideal (certainly, I wouldn't want my build to automatically install all the time, which is probably why the INSTALL project is excluded by default.). Depending on what you are doing, you might want that auto install behavior to only be tied to a Release build, or possibly introduce and Release and Install that does both. Aaron Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of david_bjorn...@agilent.com Sent: Tuesday, February 07, 2012 1:48 PM To: cmake@cmake.org Subject: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target Developers on our team have found issues with the difference between INSTALL and the default build or F7 build all under Visual Studio. My question is, there's a reasonable way to configure cmake or Visual Studio to run the INSTALL target when you hit F7 or use the default Build Solution functionality to run INSTALL. We're working a fairly large project and the default setting of having INSTALL dependent on ALL or separating out the two targets makes sense when you're building the entire project. However, we allow developers to build sub projects and it makes sense if these sub project just install quickly into a larger pre-built installation directory. The confusion currently is, they run ALL_BUILD or F7 and the build finishes and they forget to run INSTALL. Particularly we, had developers that worked formally on smaller non-Cmake Visual Studio projects and not Linux so, they're not used to the make all and then make install defacto standard. This request is similar as the following on Selecting INSTALL target in Visual Studio Configuration by default but, I wanted to see if anyone had any other suggestions on this topic. http://www.cmake.org/pipermail/cmake/2011-April/044025.html ++David-Bjornbak; This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.-- 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] Under Visual Studio , allow developers to hit F7 to run the INSTALL target
What I'm asking for is 1) or Can you set things up so that F7 does a full build and then automatically does the INSTALL target build? Developers in my team have expressed a need to hit F7 during they're day to day work and the resulting being the INSTALL target. This is not a general change I would adopt for our automated build processes and I can see the need for an individual developer using Visual Studio having this functionality e.g. hit F7 and have the INSTALL target fire off. A post build step appears to be the only present option for this request. The other alternative is to alter CMake's C++ code and change the dependency and behavior or the generator for Visual Studio. ++David-Bjornbak; From: aaron.mead...@thomsonreuters.com [mailto:aaron.mead...@thomsonreuters.com] Sent: Wednesday, February 08, 2012 7:33 AM To: BJORNBAK,DAVID (A-Sonoma,ex1); cmake@cmake.org Subject: RE: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target I had a hard time following these questions. It sounds like you're asking the following: 1) Can you set things up so that F7 does a full build and then automatically does the INSTALL target build? 2) Can you set things up so that you can build a sub project and have it install just that sub project automatically? Assuming those are your questions, I'm guessing there isn't a good way to do that automatically. Barring any better suggestions from more experienced CMaketeers, I would probably look into creating a function that adds a post build step to a project which will perform the installation of the project. Then doing a build all would cause each project to individually build and install, and building a single subproject would cause that subproject to build and install (thus solving 1 and 2 together). That doesn't seem ideal (certainly, I wouldn't want my build to automatically install all the time, which is probably why the INSTALL project is excluded by default.). Depending on what you are doing, you might want that auto install behavior to only be tied to a Release build, or possibly introduce and Release and Install that does both. Aaron Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of david_bjorn...@agilent.com Sent: Tuesday, February 07, 2012 1:48 PM To: cmake@cmake.org Subject: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target Developers on our team have found issues with the difference between INSTALL and the default build or F7 build all under Visual Studio. My question is, there's a reasonable way to configure cmake or Visual Studio to run the INSTALL target when you hit F7 or use the default Build Solution functionality to run INSTALL. We're working a fairly large project and the default setting of having INSTALL dependent on ALL or separating out the two targets makes sense when you're building the entire project. However, we allow developers to build sub projects and it makes sense if these sub project just install quickly into a larger pre-built installation directory. The confusion currently is, they run ALL_BUILD or F7 and the build finishes and they forget to run INSTALL.Particularly we, had developers that worked formally on smaller non-Cmake Visual Studio projects and not Linux so, they're not used to the make all and then make install defacto standard. This request is similar as the following on Selecting INSTALL target in Visual Studio Configuration by default but, I wanted to see if anyone had any other suggestions on this topic. http://www.cmake.org/pipermail/cmake/2011-April/044025.html ++David-Bjornbak; This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. -- 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] cmake for cygwin
On 2/7/2012 6:19 PM, Robert Dailey wrote: +1 to this as well My bad. I will get to it this week. They don't make it that easy... -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] Under Visual Studio , allow developers to hit F7 to run the INSTALL target
I wonder if you could do something like: set_target_properties(INSTALL PROPERTIES EXCLUDE_FROM_DEFAULT_BUILD 0 ) Aaron Meadows From: david_bjorn...@agilent.com [mailto:david_bjorn...@agilent.com] Sent: Wednesday, February 08, 2012 9:44 AM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target What I'm asking for is 1) or Can you set things up so that F7 does a full build and then automatically does the INSTALL target build? Developers in my team have expressed a need to hit F7 during they're day to day work and the resulting being the INSTALL target. This is not a general change I would adopt for our automated build processes and I can see the need for an individual developer using Visual Studio having this functionality e.g. hit F7 and have the INSTALL target fire off. A post build step appears to be the only present option for this request. The other alternative is to alter CMake's C++ code and change the dependency and behavior or the generator for Visual Studio. ++David-Bjornbak; From: aaron.mead...@thomsonreuters.com [mailto:aaron.mead...@thomsonreuters.com] Sent: Wednesday, February 08, 2012 7:33 AM To: BJORNBAK,DAVID (A-Sonoma,ex1); cmake@cmake.org Subject: RE: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target I had a hard time following these questions. It sounds like you're asking the following: 1) Can you set things up so that F7 does a full build and then automatically does the INSTALL target build? 2) Can you set things up so that you can build a sub project and have it install just that sub project automatically? Assuming those are your questions, I'm guessing there isn't a good way to do that automatically. Barring any better suggestions from more experienced CMaketeers, I would probably look into creating a function that adds a post build step to a project which will perform the installation of the project. Then doing a build all would cause each project to individually build and install, and building a single subproject would cause that subproject to build and install (thus solving 1 and 2 together). That doesn't seem ideal (certainly, I wouldn't want my build to automatically install all the time, which is probably why the INSTALL project is excluded by default.). Depending on what you are doing, you might want that auto install behavior to only be tied to a Release build, or possibly introduce and Release and Install that does both. Aaron Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of david_bjorn...@agilent.com Sent: Tuesday, February 07, 2012 1:48 PM To: cmake@cmake.org Subject: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target Developers on our team have found issues with the difference between INSTALL and the default build or F7 build all under Visual Studio. My question is, there's a reasonable way to configure cmake or Visual Studio to run the INSTALL target when you hit F7 or use the default Build Solution functionality to run INSTALL. We're working a fairly large project and the default setting of having INSTALL dependent on ALL or separating out the two targets makes sense when you're building the entire project. However, we allow developers to build sub projects and it makes sense if these sub project just install quickly into a larger pre-built installation directory. The confusion currently is, they run ALL_BUILD or F7 and the build finishes and they forget to run INSTALL. Particularly we, had developers that worked formally on smaller non-Cmake Visual Studio projects and not Linux so, they're not used to the make all and then make install defacto standard. This request is similar as the following on Selecting INSTALL target in Visual Studio Configuration by default but, I wanted to see if anyone had any other suggestions on this topic. http://www.cmake.org/pipermail/cmake/2011-April/044025.html ++David-Bjornbak; This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.-- 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] Under Visual Studio , allow developers to hit F7 to run the INSTALL target
I've tried similar techniques with ADD_DEPENDENCIES to ALL_BUILD and the trouble with this, within a single project these targets are not generated yet and you would have to change CMake's C++ code to change this type of behavior. CMake Error at CMakeLists.txt:231 (set_target_properties): set_target_properties Can not find target to add properties to: INSTALL You might be able to export the target but, I don't believe you can export and import INSTALL and ALL_BUILD targets in a reasonable manner. ++David-Bjornbak; From: aaron.mead...@thomsonreuters.com [mailto:aaron.mead...@thomsonreuters.com] Sent: Wednesday, February 08, 2012 7:55 AM To: BJORNBAK,DAVID (A-Sonoma,ex1); cmake@cmake.org Subject: RE: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target I wonder if you could do something like: set_target_properties(INSTALL PROPERTIES EXCLUDE_FROM_DEFAULT_BUILD 0 ) Aaron Meadows From: david_bjorn...@agilent.com [mailto:david_bjorn...@agilent.com] Sent: Wednesday, February 08, 2012 9:44 AM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target What I'm asking for is 1) or Can you set things up so that F7 does a full build and then automatically does the INSTALL target build? Developers in my team have expressed a need to hit F7 during they're day to day work and the resulting being the INSTALL target. This is not a general change I would adopt for our automated build processes and I can see the need for an individual developer using Visual Studio having this functionality e.g. hit F7 and have the INSTALL target fire off. A post build step appears to be the only present option for this request. The other alternative is to alter CMake's C++ code and change the dependency and behavior or the generator for Visual Studio. ++David-Bjornbak; From: aaron.mead...@thomsonreuters.commailto:aaron.mead...@thomsonreuters.com [mailto:aaron.mead...@thomsonreuters.com]mailto:[mailto:aaron.mead...@thomsonreuters.com] Sent: Wednesday, February 08, 2012 7:33 AM To: BJORNBAK,DAVID (A-Sonoma,ex1); cmake@cmake.orgmailto:cmake@cmake.org Subject: RE: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target I had a hard time following these questions. It sounds like you're asking the following: 1) Can you set things up so that F7 does a full build and then automatically does the INSTALL target build? 2) Can you set things up so that you can build a sub project and have it install just that sub project automatically? Assuming those are your questions, I'm guessing there isn't a good way to do that automatically. Barring any better suggestions from more experienced CMaketeers, I would probably look into creating a function that adds a post build step to a project which will perform the installation of the project. Then doing a build all would cause each project to individually build and install, and building a single subproject would cause that subproject to build and install (thus solving 1 and 2 together). That doesn't seem ideal (certainly, I wouldn't want my build to automatically install all the time, which is probably why the INSTALL project is excluded by default.). Depending on what you are doing, you might want that auto install behavior to only be tied to a Release build, or possibly introduce and Release and Install that does both. Aaron Meadows From: cmake-boun...@cmake.orgmailto:cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org]mailto:[mailto:cmake-boun...@cmake.org] On Behalf Of david_bjorn...@agilent.commailto:david_bjorn...@agilent.com Sent: Tuesday, February 07, 2012 1:48 PM To: cmake@cmake.orgmailto:cmake@cmake.org Subject: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target Developers on our team have found issues with the difference between INSTALL and the default build or F7 build all under Visual Studio. My question is, there's a reasonable way to configure cmake or Visual Studio to run the INSTALL target when you hit F7 or use the default Build Solution functionality to run INSTALL. We're working a fairly large project and the default setting of having INSTALL dependent on ALL or separating out the two targets makes sense when you're building the entire project. However, we allow developers to build sub projects and it makes sense if these sub project just install quickly into a larger pre-built installation directory. The confusion currently is, they run ALL_BUILD or F7 and the build finishes and they forget to run INSTALL.Particularly we, had developers that worked formally on smaller non-Cmake Visual Studio projects and not Linux so, they're not used to the make all and then make install defacto standard. This request is similar as the following on Selecting INSTALL target in Visual Studio Configuration by default but, I wanted to see if anyone had
Re: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target
Ah, that makes sense. Wonder how hard it would be to add a Pseudo-target to CMake for the targets it will build, and allow the scripts to set some properties on them which would be imported later as they are created... Aaron Meadows From: david_bjorn...@agilent.com [mailto:david_bjorn...@agilent.com] Sent: Wednesday, February 08, 2012 10:14 AM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target I've tried similar techniques with ADD_DEPENDENCIES to ALL_BUILD and the trouble with this, within a single project these targets are not generated yet and you would have to change CMake's C++ code to change this type of behavior. CMake Error at CMakeLists.txt:231 (set_target_properties): set_target_properties Can not find target to add properties to: INSTALL You might be able to export the target but, I don't believe you can export and import INSTALL and ALL_BUILD targets in a reasonable manner. ++David-Bjornbak; From: aaron.mead...@thomsonreuters.com [mailto:aaron.mead...@thomsonreuters.com] Sent: Wednesday, February 08, 2012 7:55 AM To: BJORNBAK,DAVID (A-Sonoma,ex1); cmake@cmake.org Subject: RE: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target I wonder if you could do something like: set_target_properties(INSTALL PROPERTIES EXCLUDE_FROM_DEFAULT_BUILD 0 ) Aaron Meadows From: david_bjorn...@agilent.com [mailto:david_bjorn...@agilent.com] Sent: Wednesday, February 08, 2012 9:44 AM To: Meadows, Aaron C.; cmake@cmake.org Subject: RE: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target What I'm asking for is 1) or Can you set things up so that F7 does a full build and then automatically does the INSTALL target build? Developers in my team have expressed a need to hit F7 during they're day to day work and the resulting being the INSTALL target. This is not a general change I would adopt for our automated build processes and I can see the need for an individual developer using Visual Studio having this functionality e.g. hit F7 and have the INSTALL target fire off. A post build step appears to be the only present option for this request. The other alternative is to alter CMake's C++ code and change the dependency and behavior or the generator for Visual Studio. ++David-Bjornbak; From: aaron.mead...@thomsonreuters.com [mailto:aaron.mead...@thomsonreuters.com] Sent: Wednesday, February 08, 2012 7:33 AM To: BJORNBAK,DAVID (A-Sonoma,ex1); cmake@cmake.org Subject: RE: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target I had a hard time following these questions. It sounds like you're asking the following: 1) Can you set things up so that F7 does a full build and then automatically does the INSTALL target build? 2) Can you set things up so that you can build a sub project and have it install just that sub project automatically? Assuming those are your questions, I'm guessing there isn't a good way to do that automatically. Barring any better suggestions from more experienced CMaketeers, I would probably look into creating a function that adds a post build step to a project which will perform the installation of the project. Then doing a build all would cause each project to individually build and install, and building a single subproject would cause that subproject to build and install (thus solving 1 and 2 together). That doesn't seem ideal (certainly, I wouldn't want my build to automatically install all the time, which is probably why the INSTALL project is excluded by default.). Depending on what you are doing, you might want that auto install behavior to only be tied to a Release build, or possibly introduce and Release and Install that does both. Aaron Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of david_bjorn...@agilent.com Sent: Tuesday, February 07, 2012 1:48 PM To: cmake@cmake.org Subject: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target Developers on our team have found issues with the difference between INSTALL and the default build or F7 build all under Visual Studio. My question is, there's a reasonable way to configure cmake or Visual Studio to run the INSTALL target when you hit F7 or use the default Build Solution functionality to run INSTALL. We're working a fairly large project and the default setting of having INSTALL dependent on ALL or separating out the two targets makes sense when you're building the entire project. However, we allow developers to build sub projects and it makes sense if these sub project just install quickly into a larger pre-built installation directory. The confusion currently is, they run ALL_BUILD or F7 and the build finishes and they forget to run INSTALL. Particularly we, had developers that worked
Re: [CMake] Making a variable a dependency...
Alexander Neundorf said the following on 2/6/2012 3:56 PM: Would it be acceptable if cmake would rerun after every build ? You could enforce that e.g. with a add_custom_command( POST_BUILD ... ) which could e.g. touch CMakeCache.txt or something. Better ideas ? We're working in a client/server environment in a fairly agile production environment; we need to have /all/ executables correctly stamped with the revision they're sourced from. So I kind of need it run before each build. Further, one of my problems is that right now the variable gets cached in CMakeCache.txt, so I have to delete CMakeCache.txt or do cmake -DSubversion_FOUND=NO or similar. In the short term, I can just make it always rebuild the revision.h, but that has the downside of causing it to /always/ rebuild the library that includes it, causing all binaries to relink, and so on, which is fairly time consuming (it's a very large project :) -- 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] Making a variable a dependency...
Michael Hertling said the following on 2/6/2012 6:39 PM:
On 02/06/2012 10:56 PM, Alexander Neundorf wrote:
On Saturday 04 February 2012, Oliver Smith wrote:
My CMakeLists uses the Subversion repository information in a couple of
places (it configures a file revision.h and it uses it for the CPack
package name).
The problem is that this variable is cached and retained until the cache
is rebuilt, instead of being calculated or evaluated per make. So if I
do a build, then do an svn update and pull some changes, it will build a
new executable but it will stamp it with the revision number from when
CMake last regenerated the make files...
Is there a way to mark a variable as volatile or something so that CMake
will always recalculate it and check if it has changed?
Would it be acceptable if cmake would rerun after every build ?
You could enforce that e.g. with a add_custom_command( POST_BUILD ... ) which
could e.g. touch CMakeCache.txt or something.
Better ideas ?
Delay the generation of the revision.h header until build phase
via a custom command; look at the following exemplary project:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
ADD_CUSTOM_COMMAND(OUTPUT dummy revision.h
COMMAND ${CMAKE_COMMAND}
-DBD=${CMAKE_BINARY_DIR}
-DWC=${CMAKE_SOURCE_DIR}
-P ${CMAKE_SOURCE_DIR}/revision.cmake)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c
#includestdio.h
#include \revision.h\
int main(void)
{
printf(\%d\\n\,REVISION); return 0;
}
)
ADD_EXECUTABLE(main main.c revision.h)
# revision.cmake:
FIND_PACKAGE(Subversion)
Subversion_WC_INFO(${WC}@HEAD P)
FILE(WRITE ${BD}/revision.h.in #define REVISION @P_WC_REVISION@\n)
CONFIGURE_FILE(${BD}/revision.h.in ${BD}/revision.h @ONLY)
A make run rebuilds the main target whenever the repository's head
revision has changed - possibly inappropriate for actual usage, just
for demonstration purposes; adapt the revision.cmake script to suit
the needs.
BTW, can anybody confirm that the above-noted example doesn't work
if the order of dummy and revision.h in the custom command is
reversed? AFAICS, revision.h is removed after being generated in
this case, so the subsequent compilation fails.
Unless I'm missing something, that won't work because P_WC_REVISION gets
cached in the CMakeCache.txt -- or does using -P cause it to skip the
caching?
- Oliver
--
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 use CMake with icc via configuration options when needing interprocedural optimization?
I think this could work, but if compiler is altered before project() call (but I didn't check this and suggest set variable only if it's not already set). Specifying only one variable in command line looks more user-friendly and robust than several ones. Anther option is using initial cache. Regards, Yuri On Wed, Feb 8, 2012 at 12:59 AM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: Hi Janitor, On Tuesday 07 February 2012, janitor 048 wrote: Hello, this is a question I recently asked on stackoverflow ( http://stackoverflow.com/questions/9129233/recommended-ways-to-use-cmake-wi th-icc-via-configuration-options) but that has not received any response since then. Maybe this mailing list is a better place to ask... Here goes I would like to use the Intel compiler icc (or icpc) with a CMake-based project (on Linux for what it's worth). I can of course export the CXX variable when calling cmake, e.g. like CXX=icpc cmake ../ and this works fine. I would however like to make this choice available via a custom option. For this I parse custom option, e.g. cmake -DMY_COMPILER_OPTION=Intel .. as IF (MY_COMPILER_OPTION STREQUAL Intel) MESSAGE(STATUS ** Compiling with Intel settings **) SET(CMAKE_CXX_COMPILER icpc) SET(CMAKE_CXX_FLAGS_RELEASE -O3 -w) SET(CMAKE_CXX_FLAGS_DEBUG -g) ENDIF () Don't do that, this is too late in the initialization process. The recommended way is to set the CXX environment variable. This is only necessary during the initial cmake run, afterwards this is stored in the cmake cmake cache. It should also work to preset the compiler variables: cmake -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc (I didn't check, but it should work). 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://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
Re: [CMake] Under Visual Studio , allow developers to hit F7 to run the INSTALL target
I use a special macro for such purposes, something like this: Sub Install() Dim prj As Project Dim sb As SolutionBuild = DTE.Solution.SolutionBuild Dim prjs As Projects = DTE.Solution.Projects For Each prj In prjs If prj.Name = INSTALL Then sb.BuildProject(sb.ActiveConfiguration.Name, prj.UniqueName) Exit For End If Next End Sub Good thing is that you can put it on toolbar or bind to hot key and run it separately (while keeping active project you're debugging). On Tue, Feb 7, 2012 at 11:47 PM, david_bjorn...@agilent.com wrote: Developers on our team have found issues with the difference between “INSTALL” and the default build or “F7” build all under Visual Studio. My question is, there’s a reasonable way to configure cmake or Visual Studio to run the INSTALL target when you hit “F7” or use the default “Build Solution” functionality to run INSTALL. ** ** We’re working a fairly large project and the default setting of having INSTALL dependent on ALL or separating out the two targets makes sense when you’re building the entire project. ** ** However, we allow developers to build sub projects and it makes sense if these sub project just install quickly into a larger pre-built installation directory. The confusion currently is, they run ALL_BUILD or “F7” and the build finishes and they forget to run “INSTALL”.Particularly we, had developers that worked formally on smaller non-Cmake Visual Studio projects and not Linux so, they’re not used to the make all and then make install defacto standard. This request is similar as the following on “Selecting INSTALL target in Visual Studio Configuration by default” but, I wanted to see if anyone had any other suggestions on this topic. http://www.cmake.org/pipermail/cmake/2011-April/044025.html ** ** ++David-Bjornbak; ** ** -- 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-commits] CMake branch, next, updated. v2.8.7-2503-g8513847
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 85138471659200d3650ea7b7d0a000ce1c873755 (commit) via 5d5bccd804f5ead01091b967a7c0aed80d58d500 (commit) from 7e8cbbe4d1d6a939ee5944a17cc7934e51f67379 (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=85138471659200d3650ea7b7d0a000ce1c873755 commit 85138471659200d3650ea7b7d0a000ce1c873755 Merge: 7e8cbbe 5d5bccd Author: Philip Lowman phi...@yhbt.com AuthorDate: Wed Feb 8 07:47:33 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Feb 8 07:47:33 2012 -0500 Merge topic 'FindProtobuf_import_dirs' into next 5d5bccd Revert FindProtobuf: Remove CMake version comments http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5d5bccd804f5ead01091b967a7c0aed80d58d500 commit 5d5bccd804f5ead01091b967a7c0aed80d58d500 Author: Philip Lowman phi...@yhbt.com AuthorDate: Wed Feb 8 07:43:44 2012 -0500 Commit: Philip Lowman phi...@yhbt.com CommitDate: Wed Feb 8 07:43:44 2012 -0500 Revert FindProtobuf: Remove CMake version comments This reverts commit 29b2426d8321d0ffb0ccc8d6cb43d614753147a6. Brings back the version number diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake index 6faa262..1e1e493 100644 --- a/Modules/FindProtobuf.cmake +++ b/Modules/FindProtobuf.cmake @@ -8,13 +8,14 @@ # for libraries and binaries. # # PROTOBUF_IMPORT_DIRS - List of additional directories to be searched for -# imported .proto files. +# imported .proto files. (New in CMake 2.8.8) # # Defines the following variables: # # PROTOBUF_FOUND - Found the Google Protocol Buffers library (libprotobuf header files) # PROTOBUF_INCLUDE_DIRS - Include directories for Google Protocol Buffers # PROTOBUF_LIBRARIES - The protobuf libraries +# [New in CMake 2.8.5] # PROTOBUF_PROTOC_LIBRARIES - The protoc libraries # PROTOBUF_LITE_LIBRARIES - The protobuf-lite libraries # @@ -23,6 +24,7 @@ # PROTOBUF_PROTOC_LIBRARY - The protoc library # PROTOBUF_INCLUDE_DIR - The include directory for protocol buffers # PROTOBUF_PROTOC_EXECUTABLE - The protoc compiler +# [New in CMake 2.8.5] # PROTOBUF_LIBRARY_DEBUG - The protobuf library (debug) # PROTOBUF_PROTOC_LIBRARY_DEBUG - The protoc library (debug) # PROTOBUF_LITE_LIBRARY - The protobuf lite library --- Summary of changes: 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-2507-gdeb6962
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 deb696247fb4a48477ed100e5ddd49f8d13e2400 (commit)
via 5db99e8708c7d329620186e4cfb6e059f400dfcc (commit)
from 778fdbe96bea2bbbc3c3e7ef07f7a841a4786eec (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=deb696247fb4a48477ed100e5ddd49f8d13e2400
commit deb696247fb4a48477ed100e5ddd49f8d13e2400
Merge: 778fdbe 5db99e8
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Feb 8 11:46:18 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Feb 8 11:46:18 2012 -0500
Merge topic 'add-CheckLanguage-module' into next
5db99e8 Add CheckLanguage module
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5db99e8708c7d329620186e4cfb6e059f400dfcc
commit 5db99e8708c7d329620186e4cfb6e059f400dfcc
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Feb 8 10:48:34 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Feb 8 10:48:34 2012 -0500
Add CheckLanguage module
Define a check_language(lang) macro to test whether lang can be
enabled. Cache the result in CMAKE_lang_COMPILER. Add a test case
covering expected results.
diff --git a/Modules/CheckLanguage.cmake b/Modules/CheckLanguage.cmake
new file mode 100644
index 000..87a4018
--- /dev/null
+++ b/Modules/CheckLanguage.cmake
@@ -0,0 +1,65 @@
+# - Check if a language can be enabled
+# Usage:
+# check_language(lang)
+# where lang is a language that may be passed to enable_language()
+# such as Fortran. If CMAKE_lang_COMPILER is already defined the
+# check does nothing. Otherwise it tries enabling the language in a
+# test project. The result is cached in CMAKE_lang_COMPILER as the
+# compiler that was found, or NOTFOUND if the language cannot be enabled.
+#
+# Example:
+# check_language(Fortran)
+# if(CMAKE_Fortran_COMPILER)
+#enable_language(Fortran)
+# else()
+#message(STATUS No Fortran support)
+# endif()
+
+#=
+# Copyright 2009-2012 Kitware, Inc.
+#
+# Distributed under the OSI-approved BSD License (the License);
+# see accompanying file Copyright.txt for details.
+#
+# This software is distributed WITHOUT ANY WARRANTY; without even the
+# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+# See the License for more information.
+#=
+# (To distribute this file outside of CMake, substitute the full
+# License text for the above reference.)
+
+macro(check_language lang)
+ if(NOT DEFINED CMAKE_${lang}_COMPILER)
+set(_desc Looking for a ${lang} compiler)
+message(STATUS ${_desc})
+file(REMOVE_RECURSE ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/Check${lang})
+file(WRITE
${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/Check${lang}/CMakeLists.txt
+ cmake_minimum_required(VERSION 2.8)
+project(Check${lang} ${lang})
+file(WRITE \\${CMAKE_CURRENT_BINARY_DIR}/result.cmake\
+ \set(CMAKE_${lang}_COMPILER ${CMAKE_${lang}_COMPILER}\\\)\\n\
+ )
+)
+execute_process(
+ WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/Check${lang}
+ COMMAND ${CMAKE_COMMAND} . -G ${CMAKE_GENERATOR}
+ OUTPUT_VARIABLE output
+ ERROR_VARIABLE output
+ RESULT_VARIABLE result
+ )
+include(${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/Check${lang}/result.cmake
OPTIONAL)
+if(CMAKE_${lang}_COMPILER AND ${result} STREQUAL 0)
+ file(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeOutput.log
+${_desc} passed with the following output:\n
+${output}\n)
+else()
+ set(CMAKE_${lang}_COMPILER NOTFOUND)
+ file(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeError.log
+${_desc} failed with the following output:\n
+${output}\n)
+endif()
+message(STATUS ${_desc} - ${CMAKE_${lang}_COMPILER})
+set(CMAKE_${lang}_COMPILER ${CMAKE_${lang}_COMPILER} CACHE FILEPATH
${lang} compiler)
+mark_as_advanced(CMAKE_${lang}_COMPILER)
+ endif()
+endmacro()
diff --git a/Tests/CMakeOnly/CMakeLists.txt b/Tests/CMakeOnly/CMakeLists.txt
index 33c426a..4407efb 100644
--- a/Tests/CMakeOnly/CMakeLists.txt
+++ b/Tests/CMakeOnly/CMakeLists.txt
@@ -17,6 +17,8 @@ add_CMakeOnly_test(CheckCXXSymbolExists)
add_CMakeOnly_test(CheckCXXCompilerFlag)
+add_CMakeOnly_test(CheckLanguage)
+
add_CMakeOnly_test(AllFindModules)
add_CMakeOnly_test(TargetScope)
diff --git a/Tests/CMakeOnly/CheckLanguage/CMakeLists.txt
b/Tests/CMakeOnly/CheckLanguage/CMakeLists.txt
new file mode 100644
[Cmake-commits] CMake branch, next, updated. v2.8.7-2514-g319ec8f
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 319ec8fe8e53b480fe6400d83887bbaee2f89695 (commit)
via 75e12d93debb950e1f82b7527b23d7c79aeec0e9 (commit)
via 0ded1778b4f857180331b7aef0b207b8fe14013d (commit)
via fee677bb29fabb273c0ac4028f0ad64a2b0cf194 (commit)
via c6827bcb61cd04a5783ae64cff3e2e819e895b95 (commit)
via 65512c37a33423db4ef458f85871f5cafc0306a3 (commit)
via 0fd099b487dfdaf8fd9865938fbef933a6e52cc5 (commit)
from deb696247fb4a48477ed100e5ddd49f8d13e2400 (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=319ec8fe8e53b480fe6400d83887bbaee2f89695
commit 319ec8fe8e53b480fe6400d83887bbaee2f89695
Merge: deb6962 75e12d9
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Feb 8 12:02:33 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Feb 8 12:02:33 2012 -0500
Merge topic 'cmake_add_fortran_subdirectory' into next
75e12d9 CMakeAddFortranSubdirectory: Add NO_EXTERNAL_INSTALL option
0ded177 CMakeAddFortranSubdirectory: Always parse arguments
fee677b Remove unused Modules/external_mingw_project.cmake.in
c6827bc Rename directory Modules/{ = CMake}AddFortranSubdirectory
65512c3 Hide CheckFortran back in Tests and use CheckLanguage instead
0fd099b Merge branch 'add-CheckLanguage-module' into
cmake_add_fortran_subdirectory
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=75e12d93debb950e1f82b7527b23d7c79aeec0e9
commit 75e12d93debb950e1f82b7527b23d7c79aeec0e9
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Feb 8 11:58:57 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Feb 8 11:58:57 2012 -0500
CMakeAddFortranSubdirectory: Add NO_EXTERNAL_INSTALL option
We do not yet support make install in the external project case.
Document this explicitly in the interface. Require the caller to use an
option to disable the unsupported behavior. This will allow us to add
the behavior by default in the future without clobbering existing
projects that handle the installation themselves.
diff --git a/Modules/CMakeAddFortranSubdirectory.cmake
b/Modules/CMakeAddFortranSubdirectory.cmake
index 681b09e..ddb79fb 100644
--- a/Modules/CMakeAddFortranSubdirectory.cmake
+++ b/Modules/CMakeAddFortranSubdirectory.cmake
@@ -19,10 +19,17 @@
# LINK_LIBRARIES # link interface libraries for LIBRARIES
#[LINK_LIBS lib dep...]...
# CMAKE_COMMAND_LINE ... # extra command line flags to pass to cmake
+# NO_EXTERNAL_INSTALL # skip installation of external project
# )
# Relative paths in ARCHIVE_DIR and RUNTIME_DIR are interpreted with respect
# to the build directory corresponding to the source directory in which the
# function is invoked.
+#
+# Limitations:
+#
+# NO_EXTERNAL_INSTALL is required for forward compatibility with a
+# future version that supports installation of the external project
+# binaries during make install.
#=
# Copyright 2011-2012 Kitware, Inc.
@@ -100,9 +107,16 @@ endfunction()
function(cmake_add_fortran_subdirectory subdir)
# Parse arguments to function
+ set(options NO_EXTERNAL_INSTALL)
set(oneValueArgs PROJECT ARCHIVE_DIR RUNTIME_DIR)
set(multiValueArgs LIBRARIES LINK_LIBRARIES CMAKE_COMMAND_LINE)
- cmake_parse_arguments(ARGS ${oneValueArgs} ${multiValueArgs} ${ARGN})
+ cmake_parse_arguments(ARGS ${options} ${oneValueArgs}
${multiValueArgs} ${ARGN})
+ if(NOT ARGS_NO_EXTERNAL_INSTALL)
+message(FATAL_ERROR
+ Option NO_EXTERNAL_INSTALL is required (for forward compatibility)
+ but was not given.
+ )
+ endif()
# if we are not using MSVC without fortran support
# then just use the usual add_subdirectory to build
diff --git a/Tests/VSGNUFortran/subdir/CMakeLists.txt
b/Tests/VSGNUFortran/subdir/CMakeLists.txt
index df018b3..0b99199 100644
--- a/Tests/VSGNUFortran/subdir/CMakeLists.txt
+++ b/Tests/VSGNUFortran/subdir/CMakeLists.txt
@@ -12,4 +12,5 @@ cmake_add_fortran_subdirectory(fortran
-DCMAKE_LIBRARY_OUTPUT_DIRECTORY=${CMAKE_LIBRARY_OUTPUT_DIRECTORY}
LINK_LIBRARIES # link interface libraries
LINK_LIBS hello world # hello needs world to link
- )
+ NO_EXTERNAL_INSTALL
+ )
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0ded1778b4f857180331b7aef0b207b8fe14013d
commit 0ded1778b4f857180331b7aef0b207b8fe14013d
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Feb 8 11:55:07 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Feb 8 11:57:00
[Cmake-commits] CMake branch, next, updated. v2.8.7-2517-g32410b6
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 32410b69501825b539ced3bc3640a60eb75d6cef (commit)
via 81228e9d1d94cb55fa0a75b474c5a3283b39551a (commit)
via 59ecc2c8ac4f6e4e3e9b20a37763365060d8bb6d (commit)
from 319ec8fe8e53b480fe6400d83887bbaee2f89695 (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=32410b69501825b539ced3bc3640a60eb75d6cef
commit 32410b69501825b539ced3bc3640a60eb75d6cef
Merge: 319ec8f 81228e9
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Feb 8 13:02:55 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Feb 8 13:02:55 2012 -0500
Merge topic 'improve-findopenmp' into next
81228e9 FindOpenMP: do not fail if only C or CXX is enabled (#11910)
59ecc2c KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=81228e9d1d94cb55fa0a75b474c5a3283b39551a
commit 81228e9d1d94cb55fa0a75b474c5a3283b39551a
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Feb 8 18:46:57 2012 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Wed Feb 8 19:01:08 2012 +0100
FindOpenMP: do not fail if only C or CXX is enabled (#11910)
Inspired-By: Raymond Wan
diff --git a/Modules/FindOpenMP.cmake b/Modules/FindOpenMP.cmake
index 652803c..ceac8d2 100644
--- a/Modules/FindOpenMP.cmake
+++ b/Modules/FindOpenMP.cmake
@@ -24,9 +24,12 @@
# (To distribute this file outside of CMake, substitute the full
# License text for the above reference.)
-include(CheckCSourceCompiles)
-include(CheckCXXSourceCompiles)
-include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
+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)
set(OpenMP_C_FLAG_CANDIDATES
#Gnu
@@ -62,8 +65,6 @@ int main() {
#endif
}
)
-# use the same source for CXX as C for now
-set(OpenMP_CXX_TEST_SOURCE ${OpenMP_C_TEST_SOURCE})
# if these are set then do not try to find them again,
# by avoiding any try_compiles for the flags
if(DEFINED OpenMP_C_FLAGS AND DEFINED OpenMP_CXX_FLAGS)
@@ -72,43 +73,68 @@ if(DEFINED OpenMP_C_FLAGS AND DEFINED OpenMP_CXX_FLAGS)
endif(DEFINED OpenMP_C_FLAGS AND DEFINED OpenMP_CXX_FLAGS)
# check c compiler
-foreach(FLAG ${OpenMP_C_FLAG_CANDIDATES})
- set(SAFE_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
- set(CMAKE_REQUIRED_FLAGS ${FLAG})
- unset(OpenMP_FLAG_DETECTED CACHE)
- message(STATUS Try OpenMP C flag = [${FLAG}])
- check_c_source_compiles(${OpenMP_CXX_TEST_SOURCE} OpenMP_FLAG_DETECTED)
- set(CMAKE_REQUIRED_FLAGS ${SAFE_CMAKE_REQUIRED_FLAGS})
- if(OpenMP_FLAG_DETECTED)
-set(OpenMP_C_FLAGS_INTERNAL ${FLAG})
-break()
- endif(OpenMP_FLAG_DETECTED)
-endforeach(FLAG ${OpenMP_C_FLAG_CANDIDATES})
+if(NOT _HAVE_LANGUAGE_C EQUAL -1)
+ include(CheckCSourceCompiles)
+
+ foreach(FLAG ${OpenMP_C_FLAG_CANDIDATES})
+set(SAFE_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
+set(CMAKE_REQUIRED_FLAGS ${FLAG})
+unset(OpenMP_FLAG_DETECTED CACHE)
+message(STATUS Try OpenMP C flag = [${FLAG}])
+check_c_source_compiles(${OpenMP_C_TEST_SOURCE} OpenMP_FLAG_DETECTED)
+set(CMAKE_REQUIRED_FLAGS ${SAFE_CMAKE_REQUIRED_FLAGS})
+if(OpenMP_FLAG_DETECTED)
+ set(OpenMP_C_FLAGS_INTERNAL ${FLAG})
+ break()
+endif(OpenMP_FLAG_DETECTED)
+ endforeach(FLAG ${OpenMP_C_FLAG_CANDIDATES})
+
+ set(OpenMP_C_FLAGS ${OpenMP_C_FLAGS_INTERNAL}
+CACHE STRING C compiler flags for OpenMP parallization)
+
+ list(APPEND _OPENMP_REQUIRED_VARS OpenMP_C_FLAGS)
+ unset(OpenMP_C_FLAG_CANDIDATES)
+endif()
# check cxx compiler
-foreach(FLAG ${OpenMP_CXX_FLAG_CANDIDATES})
- set(SAFE_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
- set(CMAKE_REQUIRED_FLAGS ${FLAG})
- unset(OpenMP_FLAG_DETECTED CACHE)
- message(STATUS Try OpenMP CXX flag = [${FLAG}])
- check_cxx_source_compiles(${OpenMP_C_TEST_SOURCE} OpenMP_FLAG_DETECTED)
- set(CMAKE_REQUIRED_FLAGS ${SAFE_CMAKE_REQUIRED_FLAGS})
- if(OpenMP_FLAG_DETECTED)
-set(OpenMP_CXX_FLAGS_INTERNAL ${FLAG})
-break()
- endif(OpenMP_FLAG_DETECTED)
-endforeach(FLAG ${OpenMP_CXX_FLAG_CANDIDATES})
-
-set(OpenMP_C_FLAGS ${OpenMP_C_FLAGS_INTERNAL}
- CACHE STRING C compiler flags for OpenMP parallization)
-
-set(OpenMP_CXX_FLAGS ${OpenMP_CXX_FLAGS_INTERNAL}
- CACHE STRING C++ compiler flags for OpenMP parallization)
-# handle the standard arguments for find_package
-find_package_handle_standard_args(OpenMP DEFAULT_MSG
- OpenMP_C_FLAGS OpenMP_CXX_FLAGS )
-
[Cmake-commits] CMake branch, next, updated. v2.8.7-2521-gcb4ed0b
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 cb4ed0b7994a04f82c14f48edb6c2c7bb2f6a046 (commit)
via c008141eee4ef2989e4b172bc1aa018255c89cd9 (commit)
from 5c79950e026019b654dc1deaa51c9521234fc655 (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=cb4ed0b7994a04f82c14f48edb6c2c7bb2f6a046
commit cb4ed0b7994a04f82c14f48edb6c2c7bb2f6a046
Merge: 5c79950 c008141
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Feb 8 14:16:18 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Feb 8 14:16:18 2012 -0500
Merge topic 'findx11-xmu' into next
c008141 FindX11: also search for Xmu (#12447)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c008141eee4ef2989e4b172bc1aa018255c89cd9
commit c008141eee4ef2989e4b172bc1aa018255c89cd9
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Feb 8 20:15:20 2012 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Wed Feb 8 20:15:20 2012 +0100
FindX11: also search for Xmu (#12447)
diff --git a/Modules/FindX11.cmake b/Modules/FindX11.cmake
index 04646c0..1735bd4 100644
--- a/Modules/FindX11.cmake
+++ b/Modules/FindX11.cmake
@@ -29,6 +29,7 @@
#X11_Xkb_INCLUDE_PATH,
X11_Xkb_FOUND
#X11_Xkblib_INCLUDE_PATH,
X11_Xkb_FOUND
#X11_Xkbfile_INCLUDE_PATH, X11_Xkbfile_LIB,
X11_Xkbfile_FOUND
+#X11_Xmu_INCLUDE_PATH, X11_Xmu_LIB,
X11_Xmu_FOUND
#X11_Xpm_INCLUDE_PATH, X11_Xpm_LIB,
X11_Xpm_FOUND
#X11_XTest_INCLUDE_PATH,X11_XTest_LIB,
X11_XTest_FOUND
#X11_Xrandr_INCLUDE_PATH, X11_Xrandr_LIB,
X11_Xrandr_FOUND
@@ -103,6 +104,7 @@ IF (UNIX)
FIND_PATH(X11_Xkb_INCLUDE_PATH X11/extensions/XKB.h
${X11_INC_SEARCH_PATH})
FIND_PATH(X11_Xkblib_INCLUDE_PATH X11/XKBlib.h
${X11_INC_SEARCH_PATH})
FIND_PATH(X11_Xkbfile_INCLUDE_PATH X11/extensions/XKBfile.h
${X11_INC_SEARCH_PATH})
+ FIND_PATH(X11_Xmu_INCLUDE_PATH X11/Xmu/Xmu.h
${X11_INC_SEARCH_PATH})
FIND_PATH(X11_Xpm_INCLUDE_PATH X11/xpm.h
${X11_INC_SEARCH_PATH})
FIND_PATH(X11_XTest_INCLUDE_PATH X11/extensions/XTest.h
${X11_INC_SEARCH_PATH})
FIND_PATH(X11_XShm_INCLUDE_PATH X11/extensions/XShm.h
${X11_INC_SEARCH_PATH})
@@ -134,6 +136,7 @@ IF (UNIX)
FIND_LIBRARY(X11_Xinerama_LIB Xinerama ${X11_LIB_SEARCH_PATH})
FIND_LIBRARY(X11_Xinput_LIB Xi ${X11_LIB_SEARCH_PATH})
FIND_LIBRARY(X11_Xkbfile_LIB xkbfile ${X11_LIB_SEARCH_PATH})
+ FIND_LIBRARY(X11_Xmu_LIB Xmu ${X11_LIB_SEARCH_PATH})
FIND_LIBRARY(X11_Xpm_LIB Xpm ${X11_LIB_SEARCH_PATH})
FIND_LIBRARY(X11_Xrandr_LIB Xrandr ${X11_LIB_SEARCH_PATH})
FIND_LIBRARY(X11_Xrender_LIB Xrender ${X11_LIB_SEARCH_PATH})
@@ -297,6 +300,11 @@ IF (UNIX)
SET(X11_INCLUDE_DIR ${X11_INCLUDE_DIR} ${X11_Xkbfile_INCLUDE_PATH} )
ENDIF (X11_Xkbfile_INCLUDE_PATH AND X11_Xkbfile_LIB AND
X11_Xlib_INCLUDE_PATH)
+ IF (X11_Xmu_INCLUDE_PATH AND X11_Xmu_LIB)
+ SET(X11_Xmu_FOUND TRUE)
+ SET(X11_INCLUDE_DIR ${X11_INCLUDE_DIR} ${X11_Xmu_INCLUDE_PATH})
+ ENDIF (X11_Xmu_INCLUDE_PATH AND X11_Xmu_LIB)
+
IF (X11_Xinput_INCLUDE_PATH AND X11_Xinput_LIB)
SET(X11_Xinput_FOUND TRUE)
SET(X11_INCLUDE_DIR ${X11_INCLUDE_DIR} ${X11_Xinput_INCLUDE_PATH})
@@ -456,6 +464,8 @@ IF (UNIX)
X11_Xkblib_INCLUDE_PATH
X11_Xkbfile_INCLUDE_PATH
X11_Xkbfile_LIB
+X11_Xmu_INCLUDE_PATH
+X11_Xmu_LIB
X11_Xscreensaver_INCLUDE_PATH
X11_Xscreensaver_LIB
X11_Xpm_INCLUDE_PATH
---
Summary of changes:
Modules/FindX11.cmake | 10 ++
1 files changed, 10 insertions(+), 0 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-2523-g7c20788
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 7c20788c16f5092060d27c3d7741f8685d67ded9 (commit) via bb5f48fe99b3b6d66d7ae6b6c4ae6ac07969e5e2 (commit) from cb4ed0b7994a04f82c14f48edb6c2c7bb2f6a046 (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=7c20788c16f5092060d27c3d7741f8685d67ded9 commit 7c20788c16f5092060d27c3d7741f8685d67ded9 Merge: cb4ed0b bb5f48f Author: Rolf Eike Beer e...@sf-mail.de AuthorDate: Wed Feb 8 14:29:50 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Feb 8 14:29:50 2012 -0500 Merge topic 'PGI-recognise-pgfortran' into next bb5f48f detect pgfortran as PGI Fortran compiler (#12425) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb5f48fe99b3b6d66d7ae6b6c4ae6ac07969e5e2 commit bb5f48fe99b3b6d66d7ae6b6c4ae6ac07969e5e2 Author: Rolf Eike Beer e...@sf-mail.de AuthorDate: Wed Feb 8 20:26:27 2012 +0100 Commit: Rolf Eike Beer e...@sf-mail.de CommitDate: Wed Feb 8 20:26:27 2012 +0100 detect pgfortran as PGI Fortran compiler (#12425) See http://www.pgroup.com/doc/pgiug.pdf, page xviii. diff --git a/Modules/CMakeDetermineFortranCompiler.cmake b/Modules/CMakeDetermineFortranCompiler.cmake index efcba29..ade6d58 100644 --- a/Modules/CMakeDetermineFortranCompiler.cmake +++ b/Modules/CMakeDetermineFortranCompiler.cmake @@ -50,7 +50,7 @@ IF(NOT CMAKE_Fortran_COMPILER) # fort77: native F77 compiler under HP-UX (and some older Crays) # frt: Fujitsu F77 compiler # pathf90/pathf95/pathf2003: PathScale Fortran compiler -# pgf77/pgf90/pgf95: Portland Group F77/F90/F95 compilers +# pgf77/pgf90/pgf95/pgfortran: Portland Group F77/F90/F95 compilers # xlf/xlf90/xlf95: IBM (AIX) F77/F90/F95 compilers # lf95: Lahey-Fujitsu F95 compiler # fl32: Microsoft Fortran 77 PowerStation compiler @@ -64,8 +64,8 @@ IF(NOT CMAKE_Fortran_COMPILER) # then 77 or older compilers, gnu is always last in the group, # so if you paid for a compiler it is picked by default. SET(CMAKE_Fortran_COMPILER_LIST - ifort ifc af95 af90 efc f95 pathf2003 pathf95 pgf95 lf95 xlf95 fort - gfortran gfortran-4 g95 f90 pathf90 pgf90 xlf90 epcf90 fort77 + ifort ifc af95 af90 efc f95 pathf2003 pathf95 pgf95 pgfortran lf95 xlf95 + fort gfortran gfortran-4 g95 f90 pathf90 pgf90 xlf90 epcf90 fort77 frt pgf77 xlf fl32 af77 g77 f77 ) @@ -73,7 +73,7 @@ IF(NOT CMAKE_Fortran_COMPILER) SET(_Fortran_COMPILER_NAMES_GNU gfortran gfortran-4 g95 g77) SET(_Fortran_COMPILER_NAMES_Intel ifort ifc efc) SET(_Fortran_COMPILER_NAMES_Absoftaf95 af90 af77) -SET(_Fortran_COMPILER_NAMES_PGI pgf95 pgf90 pgf77) +SET(_Fortran_COMPILER_NAMES_PGI pgf95 pgfortran pgf90 pgf77) SET(_Fortran_COMPILER_NAMES_PathScale pathf2003 pathf95 pathf90) SET(_Fortran_COMPILER_NAMES_XLxlf) SET(_Fortran_COMPILER_NAMES_VisualAge xlf95 xlf90 xlf) --- Summary of changes: Modules/CMakeDetermineFortranCompiler.cmake |8 1 files changed, 4 insertions(+), 4 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-2527-ge36cce1
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 e36cce123f4e5449fe6f8bfa22d5f3881d94e533 (commit)
via cbdfcc6515a58731308d21bb3c5cbaa513503c01 (commit)
from f2b7a4781f9f3fcda3647eafd43b8b967a118b6a (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=e36cce123f4e5449fe6f8bfa22d5f3881d94e533
commit e36cce123f4e5449fe6f8bfa22d5f3881d94e533
Merge: f2b7a47 cbdfcc6
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Wed Feb 8 20:42:18 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Feb 8 20:42:18 2012 -0500
Merge topic 'qt4-warning-clarification' into next
cbdfcc6 FindQt4: clarify warning message about incorrect Qt installation.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cbdfcc6515a58731308d21bb3c5cbaa513503c01
commit cbdfcc6515a58731308d21bb3c5cbaa513503c01
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Wed Feb 8 18:40:55 2012 -0700
Commit: Clinton Stimpson clin...@elemtech.com
CommitDate: Wed Feb 8 18:40:55 2012 -0700
FindQt4: clarify warning message about incorrect Qt installation.
Fixes bug #12915.
Thanks Laurent Rineau and Brad King for input.
diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake
index c56827e..9b646b4 100644
--- a/Modules/FindQt4.cmake
+++ b/Modules/FindQt4.cmake
@@ -588,8 +588,9 @@ IF (QT_QMAKE_EXECUTABLE AND QTVERSION)
SET(QT_LIBRARY_DIR ${QT_LIBRARY_DIR_TMP} CACHE INTERNAL Qt library dir
FORCE)
SET(QT_QTCORE_FOUND 1)
ELSE()
-MESSAGE(Warning: QT_QMAKE_EXECUTABLE reported QT_INSTALL_LIBS as
${QT_LIBRARY_DIR_TMP})
-MESSAGE(Warning: But QtCore couldn't be found. Qt must NOT be installed
correctly, or it wasn't found for cross compiling.)
+MESSAGE(WARNING ${QT_QMAKE_EXECUTABLE} reported QT_INSTALL_LIBS as
\${QT_LIBRARY_DIR_TMP}\
+but QtCore could not be found there.
+Qt is NOT installed correctly for the target build
environment.)
IF(Qt4_FIND_REQUIRED)
MESSAGE( FATAL_ERROR Could NOT find QtCore. Check
${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeError.log for more details.)
ENDIF(Qt4_FIND_REQUIRED)
---
Summary of changes:
Modules/FindQt4.cmake |5 +++--
1 files changed, 3 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, next, updated. v2.8.7-2529-g267cc72
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 267cc72af16065a85f935d6e046d6cf8a604fc28 (commit)
via 7a6d2796e63a8a390bd86fe9a029c4add119132b (commit)
from e36cce123f4e5449fe6f8bfa22d5f3881d94e533 (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=267cc72af16065a85f935d6e046d6cf8a604fc28
commit 267cc72af16065a85f935d6e046d6cf8a604fc28
Merge: e36cce1 7a6d279
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Wed Feb 8 21:02:12 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Feb 8 21:02:12 2012 -0500
Merge topic 'qt4-translation-includes' into next
7a6d279 FindQt4: Add include directories for lupdate.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7a6d2796e63a8a390bd86fe9a029c4add119132b
commit 7a6d2796e63a8a390bd86fe9a029c4add119132b
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Wed Feb 8 19:01:29 2012 -0700
Commit: Clinton Stimpson clin...@elemtech.com
CommitDate: Wed Feb 8 19:01:29 2012 -0700
FindQt4: Add include directories for lupdate.
Fixes bug #12644.
Thanks Bernd Lörwald for partial patch.
diff --git a/Modules/Qt4Macros.cmake b/Modules/Qt4Macros.cmake
index 4da1a3f..f327125 100644
--- a/Modules/Qt4Macros.cmake
+++ b/Modules/Qt4Macros.cmake
@@ -393,7 +393,13 @@ MACRO(QT4_CREATE_TRANSLATION _qm_files)
FOREACH(_pro_src ${_my_sources})
SET(_pro_srcs ${_pro_srcs} \${_pro_src}\)
ENDFOREACH(_pro_src ${_my_sources})
- FILE(WRITE ${_ts_pro} SOURCES = ${_pro_srcs})
+ SET(_pro_includes)
+ GET_DIRECTORY_PROPERTY(_inc_DIRS INCLUDE_DIRECTORIES)
+ FOREACH(_pro_include ${_inc_DIRS})
+ GET_FILENAME_COMPONENT(_abs_include ${_pro_include} ABSOLUTE)
+ SET(_pro_includes ${_pro_includes} \${_abs_include}\)
+ ENDFOREACH(_pro_include ${CMAKE_CXX_INCLUDE_PATH})
+ FILE(WRITE ${_ts_pro} SOURCES = ${_pro_srcs}\nINCLUDEPATH =
${_pro_includes}\n)
ENDIF(_my_sources)
ADD_CUSTOM_COMMAND(OUTPUT ${_ts_file}
COMMAND ${QT_LUPDATE_EXECUTABLE}
---
Summary of changes:
Modules/Qt4Macros.cmake |8 +++-
1 files changed, 7 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, master, updated. v2.8.7-307-g16b1a6e
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 16b1a6e4e07b223c7ead20cd40346fc327e90569 (commit) from 59ecc2c8ac4f6e4e3e9b20a37763365060d8bb6d (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=16b1a6e4e07b223c7ead20cd40346fc327e90569 commit 16b1a6e4e07b223c7ead20cd40346fc327e90569 Author: KWSys Robot kwro...@kitware.com AuthorDate: Thu Feb 9 00:05:06 2012 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Thu Feb 9 00:05:06 2012 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 17f7339..7b31670 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 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
[Cmake-commits] CMake branch, next, updated. v2.8.7-2531-g64dc971
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 64dc9710d533f076b2f1cfe3201beba5e0998e64 (commit)
via e69e816d21732b092b33ff7d36b7cc478350344e (commit)
from 267cc72af16065a85f935d6e046d6cf8a604fc28 (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=64dc9710d533f076b2f1cfe3201beba5e0998e64
commit 64dc9710d533f076b2f1cfe3201beba5e0998e64
Merge: 267cc72 e69e816
Author: Alexey Ozeritsky aozerit...@gmail.com
AuthorDate: Thu Feb 9 01:45:55 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 9 01:45:55 2012 -0500
Merge topic 'findblas-bugs' into next
e69e816 FindBLAS/FindLAPACK: 0012924 fixed, 0012925 fixed
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e69e816d21732b092b33ff7d36b7cc478350344e
commit e69e816d21732b092b33ff7d36b7cc478350344e
Author: Alexey Ozeritsky aozerit...@gmail.com
AuthorDate: Sun Feb 5 18:01:38 2012 +0400
Commit: Alexey Ozeritsky aozerit...@gmail.com
CommitDate: Sun Feb 5 18:07:18 2012 +0400
FindBLAS/FindLAPACK: 0012924 fixed, 0012925 fixed
diff --git a/Modules/FindBLAS.cmake b/Modules/FindBLAS.cmake
index 9b76d90..4efb6ec 100644
--- a/Modules/FindBLAS.cmake
+++ b/Modules/FindBLAS.cmake
@@ -23,6 +23,7 @@
##
### List of vendors (BLA_VENDOR) valid in this module
## Goto,ATLAS PhiPACK,CXML,DXML,SunPerf,SCSL,SGIMATH,IBMESSL,Intel10_32
(intel mkl v10 32 bit),Intel10_64lp (intel mkl v10 64 bit,lp thread model, lp64
model),
+## Intel10_64lp_seq (intel mkl v10 64 bit,sequential code, lp64 model),
## Intel( older versions of mkl 32 and 64 bit), ACML,ACML_MP,ACML_GPU,Apple,
NAS, Generic
# C/CXX should be enabled to use Intel mkl
@@ -85,6 +86,7 @@ if (NOT _libdir)
set(_libdir /usr/local/lib /usr/lib /usr/local/lib64 /usr/lib64 ENV
LD_LIBRARY_PATH)
endif ()
endif ()
+
foreach(_library ${_list})
set(_combined_name ${_combined_name}_${_library})
@@ -108,6 +110,7 @@ foreach(_library ${_list})
NAMES ${_library}
PATHS ${_libdir}
)
+#message(FATAL - found ${${_prefix}_${_library}_LIBRARY})
mark_as_advanced(${_prefix}_${_library}_LIBRARY)
set(${LIBRARIES} ${${LIBRARIES}} ${${_prefix}_${_library}_LIBRARY})
set(_libraries_work ${${_prefix}_${_library}_LIBRARY})
@@ -115,7 +118,7 @@ foreach(_library ${_list})
endforeach(_library ${_list})
if(_libraries_work)
# Test this combination of libraries.
- set(CMAKE_REQUIRED_LIBRARIES ${_flags} ${${LIBRARIES}} ${_threads})
+ set(CMAKE_REQUIRED_LIBRARIES ${_flags} ${${LIBRARIES}} ${_thread})
# message(DEBUG: CMAKE_REQUIRED_LIBRARIES = ${CMAKE_REQUIRED_LIBRARIES})
if (_CHECK_FORTRAN)
check_fortran_function_exists(${_name} ${_prefix}${_combined_name}_WORKS)
@@ -460,117 +463,99 @@ if (BLA_VENDOR MATCHES Intel* OR BLA_VENDOR STREQUAL
All)
else(BLAS_FIND_QUIETLY OR NOT BLAS_FIND_REQUIRED)
find_package(Threads REQUIRED)
endif(BLAS_FIND_QUIETLY OR NOT BLAS_FIND_REQUIRED)
- if (WIN32)
+
+ set(BLAS_SEARCH_LIBS )
+
if(BLA_F95)
-if(NOT BLAS95_LIBRARIES)
-check_fortran_libraries(
-BLAS95_LIBRARIES
-BLAS
-sgemm
-
-mkl_blas95;mkl_intel_c;mkl_intel_thread;mkl_core;libguide40
-
-)
-endif(NOT BLAS95_LIBRARIES)
- else(BLA_F95)
-if(NOT BLAS_LIBRARIES)
-check_fortran_libraries(
-BLAS_LIBRARIES
-BLAS
-SGEMM
-
-mkl_c_dll;mkl_intel_thread_dll;mkl_core_dll;libguide40
-
-)
-endif(NOT BLAS_LIBRARIES)
- endif(BLA_F95)
- else(WIN32)
- if (BLA_VENDOR STREQUAL Intel10_32 OR BLA_VENDOR STREQUAL All)
-if(BLA_F95)
- if(NOT BLAS95_LIBRARIES)
- check_fortran_libraries(
- BLAS95_LIBRARIES
- BLAS
- sgemm
-
- mkl_blas95;mkl_intel;mkl_intel_thread;mkl_core;guide
- ${CMAKE_THREAD_LIBS_INIT};${LM}
- )
- endif(NOT BLAS95_LIBRARIES)
-else(BLA_F95)
-if(NOT BLAS_LIBRARIES)
- check_fortran_libraries(
- BLAS_LIBRARIES
- BLAS
- sgemm
-
- mkl_intel;mkl_intel_thread;mkl_core;guide
- ${CMAKE_THREAD_LIBS_INIT}
- ${LM}
- )
- endif(NOT BLAS_LIBRARIES)
-endif(BLA_F95)
- endif (BLA_VENDOR STREQUAL Intel10_32 OR BLA_VENDOR STREQUAL All)
- if (BLA_VENDOR STREQUAL Intel10_64lp OR BLA_VENDOR STREQUAL All)
- if(BLA_F95)
-if(NOT BLAS95_LIBRARIES)
- check_fortran_libraries(
- BLAS95_LIBRARIES
- BLAS
- sgemm
-
- mkl_blas95;mkl_intel_lp64;mkl_intel_thread;mkl_core;guide
- ${CMAKE_THREAD_LIBS_INIT};${LM}
- )
-endif(NOT BLAS95_LIBRARIES)
- else(BLA_F95)
- if(NOT BLAS_LIBRARIES)
+
