Re: [cmake-developers] XCode recursive folders support
On 02/15/2011 08:39 AM, Johan Björk wrote: Hi everyone, I created a patch which adds support for multiple folders in Xcode; http://www.vtk.org/Bug/view.php?id=10039 I wasn't able to find a good place for common string helpers or similar, in cmSourceGroupCommand.cxx, there is an inline copy of a tokenize() function which I bluntly copied to cmGlobalXCodeGenerator.cxx in my patch, but that's really ugly :(. Where should code like that go? In KWSys? Please factor it out into cmSystemTools.(h|cxx). Thanks, -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] XCode recursive folders support
Thanks done. /Johan On Tue, Feb 15, 2011 at 3:00 PM, Brad King brad.k...@kitware.com wrote: On 02/15/2011 08:39 AM, Johan Björk wrote: Hi everyone, I created a patch which adds support for multiple folders in Xcode; http://www.vtk.org/Bug/view.php?id=10039 I wasn't able to find a good place for common string helpers or similar, in cmSourceGroupCommand.cxx, there is an inline copy of a tokenize() function which I bluntly copied to cmGlobalXCodeGenerator.cxx in my patch, but that's really ugly :(. Where should code like that go? In KWSys? Please factor it out into cmSystemTools.(h|cxx). Thanks, -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Setting target destination and rpath per generator
2011/2/15 Daryl N darylhouse2...@yahoo.com:
Hi,
I have a question on the use of CPack. I have CMake setup to generate
binaries and shared libraries. Up until now I have only created a TGZ with
rpath set to .. This has worked nicely, but now I would like to create a
Debian package for proper installation. I have added DEB to CPACK_GENERATOR
and I've created my own cpack_config.cmake file. My goal is:
1. Run cmake/make package once and create the tar.gz file with all exe/libs
in the root folder of the tar.gz file with rpath set to ..
2. Create new .deb package with exes in /usr/local/bin and libs in
/usr/local/lib. Alternatively, since files are private, all could be put in
/usr/local/some folder.
I've attempted this by creating my own cpack_config.cmake file to try to
override some settings per generator. Some observations:
1. I've been unable to set the install(target DESTINATION) path per
generator in my cpack_config.cmake file. Whatever the variable is set to
when the install(...) is processed in the CMakeLists.txt file is what is
used for all generators. Just want to confirm changing this isn't an option
per generator.
The above has prevented me from having my install lines like:
install(target DESTINATION ${BIN_PATH})
install(target DESTINATION ${LIB_PATH})
and then setting BIN_PATH to bin and LIB_PATH to lib for DEB, but setting
them to . for TGZ, since I can't change the variable in
.
I suppose cpack_config.cmake is your CPACK_PROJECT_CONFIG_FILE.
As far as I know you cannot change install rules on CPack generator basis.
install rules belongs to CMakeLists.txt and they are evaluated at CMake-time
(not CPack-time).
cpack_config.cmake is evaluated at CPack-time, i.e. when CPack runs.
You can do CPack-generator specific actions in this file.
(like setting CPACK_SET_DESTDIR OFF or ON or changing
CPACK_PACKAGING_INSTALL_PREFIX etc...)
I did not tried playing with rpath but may be you can
if(CPACK_GENERATOR MATCHES TGZ)
set(CMAKE_INSTALL_RPATH .)
set(CPACK_SET_DESTDIR OFF)
endif(CPACK_GENERATOR MATCHES TGZ)
if(CPACK_GENERATOR MATCHES DEB)
set(CPACK_PACKAGING_INSTALL_PREFIX /usr/local/somefolder)
endif(CPACK_GENERATOR MATCHES DEB)
2. I would also like to set the rpath per generator. So the targets in the
TGZ only look in . while the DEB installed targets only look in
/usr/local/some folder. But I haven't been able to update the rpath per
generator in cpack_config.cmake. I've tried both setting
CMAKE_INSTALL_RPATH and using set_target_properties(... PROPERTIES
INSTALL_RPATH). Again, I'm assuming this can't be changed at CPack time.
I don't know whether if CMAKE_INSTALL_RPATH can be changed at CPack time
(as I suggested in my previous example) you'll have to try and
may be verify in the CMake source code in order to check when it is handled.
Whatever the current status,
I don't see why it couldn't be handled at CPack time
(but I may be missing something).
Do I need to run cpack
separately changing the variables before hand? I suppose that would mean 2
builds cycles also, once for each generator.
2 build cycles will definitely work.
However if you gives us more information on what's inside your
cpack_config.cmake
what works what does not work with it, may be we can see if it it can
be done in a single build.
I think the main issue is the fact that as far as I understand your
need you want
to put all files (libs, exe) in a single folder for the TGZ and have
prefix+/lib, prefix+/bin
in the DEB case?
Changing the prefix is easy but adding (or removing) the extra /lib
and /bin I don't
currently know how to do that. Why won't you keep the lib and bin
suffix in the TGZ case?
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPACK_STRIP_FILES has no effect on DSOs
On 02/11/2011 11:38 AM, Eric Noulard wrote: So you may perfectly have shared lib in your build tree which are not stripped and get them stripped in the package. Ha! I did not check that; i.e. we alway run 'make install' before 'make package' and I presumed that install location was where the stripped binaries were to be found. That makes a lot of sense now. So bottom line: it works and I rattled the cages for nothing. Cheers and sorry about the noise, .mm ___ 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] Global STATIC_LIBRARY_FLAGS_configuration ?
Hi guys, Any plans to add a CMAKE_STATIC_LIBRARY_FLAGS_configuration ? It seems rather weird that I can set 'global' linking flags as well as compilation flags, but that the static_library step flags are tied to a target. I know this can all be 'hacked' with overriding the add_library() call, but it's not very pretty. Anyone? Thanks /Johan ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake Error: Cannot determine link language for target
Hi , I do get this error while build a application using CMAKE. Please help me in resolving this one. I tried to use the SET_TARGET_PROPERTIES but not successful. I do have mix of C and C++ static libs in my project. -- Thanks Regards, Kiran Patil ___ 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 Error: Cannot determine link language for target
Show us your code. On Tue, Feb 15, 2011 at 8:08 AM, Kiran Gopal Patil pati...@gmail.comwrote: Hi , I do get this error while build a application using CMAKE. Please help me in resolving this one. I tried to use the SET_TARGET_PROPERTIES but not successful. I do have mix of C and C++ static libs in my project. -- Thanks Regards, Kiran Patil ___ 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] FIND_PATH issue in FindQt4.cmake
Hi All,
Thanks for the help so far, I will check and see if CMake 2.8.4rc has the
same issue meanwhile I noticed that FIND_PATH seems to have special
instructions for Darwin machines with the use of CMAKE_FIND_FRAMEWORK on
page http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_path
The notes are a little confusing: it says CMAKE_FIND_FRAMEWORK defaults to
FIRST on Darwin systems which I can interpret one of two ways.
First, If a standard library and a framework are found in the same search
order then CMAKE will use this variable to determine which to pick first.
Second, if a framework is found regardless of where it is in the search
order it will be picked. I suspect the choice is the first one. However, in
my test I found that if I set CMAKE_FIND_FRAMEWORK to be LAST then CMAKE
picks the proper path. This would make me think the second option is at play
or it is just pure coincidence that this option happened to give me the
correct result.
Any of you know what the correct option is? To me it would make sense that
FIND_PATH honors the search order which would mean that the HINTS option in
FindQt4 should have higher precedence than the Framework in the
CMAKE_SYSTEM_FRAMEWORK_PATH.
Thanks,
Hari
On Mon, Feb 14, 2011 at 11:54 PM, Andreas Pakulat ap...@gmx.de wrote:
On 14.02.11 16:18:09, Clinton Stimpson wrote:
On Monday, February 14, 2011 03:27:11 pm Harinarayan Krishnan wrote:
Hi All,
I was trying to build the VisIt software package on my Mac OSX 1.5 .
This
package uses Qt 4.6.1 during its build. I ran into an issue where the
QtCore path finds my globally installed version of Qt (4.7) as apposed
to
the Qt (4.6.1).
While digging around I found that FIND_PATH (code included below) in
FindQt4.cmake is pulling information from the system path and assigning
this value to the QT_QTCORE_INCLUDE_DIR. This is causing a build
failure
where the rest of the QT headers are using 4.6.1 and QtCore is using
version 4.7.
The value in ${qt_headers} points to the correct 4.6.1 location yet
FIND_PATH does not use this parameter. Any ideas?
_qt4_query_qmake(QT_INSTALL_HEADERS qt_headers)
SET(QT_QTCORE_INCLUDE_DIR NOTFOUND)
FIND_PATH(QT_QTCORE_INCLUDE_DIR QtCore
HINTS ${qt_headers}
${QT_LIBRARY_DIR}/QtCore.framework/Headers
PATH_SUFFIXES QtCore
)
Ok, I'm able to reproduce this problem.
I did notice that if I add the NO_CMAKE_SYSTEM_PATH option, then the
problem
goes away. But, I thought HINTS had a higher priority than paths from
the
Mac's platform files.
And, I don't see this problem on Linux.
Is this a bug in find_path() ??
Definetly, the only thing that has higher priority than HINTS are values
from the cmake or environment variables CMAKE_PREFIX_PATH,
CMAKE_INCLUDE_PATH and CMAKE_FRAMEWORK_PATH. There's no special
behaviour for MacOSX documented.
Someone should file a bugreport after verifying this still happens with
the latest rc of 2.8.4.
Andreas
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
___
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 time is right to make new friends.
___
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] Setting target destination and rpath per generator
Sorry, don't know how to reply inline with this editor. Yes,
cpack_config.cmake
is my CPACK_PROJECT_CONFIG_FILE. For rpath, here is what I have in the cpack
config file:
if (${CPACK_GENERATOR} STREQUAL TGZ)
set(CPACK_SET_DESTDIR OFF)
set(CMAKE_INSTALL_RPATH .)
set_target_properties(npManager
PROPERTIES INSTALL_RPATH .)
elseif (${CPACK_GENERATOR} STREQUAL DEB)
set(CPACK_SET_DESTDIR ON)
set(CMAKE_INSTALL_RPATH /usr/local/some folder)
set_target_properties(npManager
PROPERTIES INSTALL_RPATH /usr/local/some folder)
endif ()
CMAKE_INSTALL_RPATH was initially set to /user/local/some folder in my main
CMakeLists.txt file and it stays that way in TGZ even with the sets above. For
the TGZ file I want to be able to unpack it and then just run it locally. If I
use the bin/lib folder structure in the TGZ, then I would need to set rpath to
../lib for them to be found. And then that would be part of the rpath for
the
DEB package too. Sounds like 2 build cycles may be needed.
Daryl
From: Eric Noulard eric.noul...@gmail.com
To: Daryl N darylhouse2...@yahoo.com
Cc: cmake@cmake.org
Sent: Tue, February 15, 2011 4:00:17 AM
Subject: Re: [CMake] Setting target destination and rpath per generator
2011/2/15 Daryl N darylhouse2...@yahoo.com:
Hi,
I have a question on the use of CPack. I have CMake setup to generate
binaries and shared libraries. Up until now I have only created a TGZ with
rpath set to .. This has worked nicely, but now I would like to create a
Debian package for proper installation. I have added DEB to CPACK_GENERATOR
and I've created my own cpack_config.cmake file. My goal is:
1. Run cmake/make package once and create the tar.gz file with all exe/libs
in the root folder of the tar.gz file with rpath set to ..
2. Create new .deb package with exes in /usr/local/bin and libs in
/usr/local/lib. Alternatively, since files are private, all could be put in
/usr/local/some folder.
I've attempted this by creating my own cpack_config.cmake file to try to
override some settings per generator. Some observations:
1. I've been unable to set the install(target DESTINATION) path per
generator in my cpack_config.cmake file. Whatever the variable is set to
when the install(...) is processed in the CMakeLists.txt file is what is
used for all generators. Just want to confirm changing this isn't an option
per generator.
The above has prevented me from having my install lines like:
install(target DESTINATION ${BIN_PATH})
install(target DESTINATION ${LIB_PATH})
and then setting BIN_PATH to bin and LIB_PATH to lib for DEB, but setting
them to . for TGZ, since I can't change the variable in
.
I suppose cpack_config.cmake is your CPACK_PROJECT_CONFIG_FILE.
As far as I know you cannot change install rules on CPack generator basis.
install rules belongs to CMakeLists.txt and they are evaluated at CMake-time
(not CPack-time).
cpack_config.cmake is evaluated at CPack-time, i.e. when CPack runs.
You can do CPack-generator specific actions in this file.
(like setting CPACK_SET_DESTDIR OFF or ON or changing
CPACK_PACKAGING_INSTALL_PREFIX etc...)
I did not tried playing with rpath but may be you can
if(CPACK_GENERATOR MATCHES TGZ)
set(CMAKE_INSTALL_RPATH .)
set(CPACK_SET_DESTDIR OFF)
endif(CPACK_GENERATOR MATCHES TGZ)
if(CPACK_GENERATOR MATCHES DEB)
set(CPACK_PACKAGING_INSTALL_PREFIX /usr/local/somefolder)
endif(CPACK_GENERATOR MATCHES DEB)
2. I would also like to set the rpath per generator. So the targets in the
TGZ only look in . while the DEB installed targets only look in
/usr/local/some folder. But I haven't been able to update the rpath per
generator in cpack_config.cmake. I've tried both setting
CMAKE_INSTALL_RPATH and using set_target_properties(... PROPERTIES
INSTALL_RPATH). Again, I'm assuming this can't be changed at CPack time.
I don't know whether if CMAKE_INSTALL_RPATH can be changed at CPack time
(as I suggested in my previous example) you'll have to try and
may be verify in the CMake source code in order to check when it is handled.
Whatever the current status,
I don't see why it couldn't be handled at CPack time
(but I may be missing something).
Do I need to run cpack
separately changing the variables before hand? I suppose that would mean 2
builds cycles also, once for each generator.
2 build cycles will definitely work.
However if you gives us more information on what's inside your
cpack_config.cmake
what works what does not work with it, may be we can see if it it can
be done in a single build.
I think the main issue is the fact that as far as I understand your
need you want
to put all files (libs, exe) in a single folder for the TGZ and have
prefix+/lib, prefix+/bin
in the DEB case?
Changing the prefix is easy but adding (or removing) the extra /lib
and /bin I don't
currently know how to do that. Why won't you keep the lib and bin
suffix in the
Re: [CMake] Setting target destination and rpath per generator
You cannot do cmake-ish things in the CPACK_PROJECT_CONFIG_FILE.
Neither install commands nor set_target_properties calls do anything in this
context.
On Tue, Feb 15, 2011 at 9:36 AM, Daryl N darylhouse2...@yahoo.com wrote:
Sorry, don't know how to reply inline with this editor. Yes,
cpack_config.cmake is my CPACK_PROJECT_CONFIG_FILE. For rpath, here is what
I have in the cpack config file:
if (${CPACK_GENERATOR} STREQUAL TGZ)
set(CPACK_SET_DESTDIR OFF)
set(CMAKE_INSTALL_RPATH .)
set_target_properties(npManager
PROPERTIES INSTALL_RPATH .)
elseif (${CPACK_GENERATOR} STREQUAL DEB)
set(CPACK_SET_DESTDIR ON)
set(CMAKE_INSTALL_RPATH /usr/local/some folder)
set_target_properties(npManager
PROPERTIES INSTALL_RPATH /usr/local/some
folder)
endif ()
CMAKE_INSTALL_RPATH was initially set to /user/local/some folder in my
main CMakeLists.txt file and it stays that way in TGZ even with the sets
above. For the TGZ file I want to be able to unpack it and then just run it
locally. If I use the bin/lib folder structure in the TGZ, then I would
need to set rpath to ../lib for them to be found. And then that would be
part of the rpath for the DEB package too. Sounds like 2 build cycles may
be needed.
Daryl*
From:* Eric Noulard eric.noul...@gmail.com
*To:* Daryl N darylhouse2...@yahoo.com
*Cc:* cmake@cmake.org
*Sent:* Tue, February 15, 2011 4:00:17 AM
*Subject:* Re: [CMake] Setting target destination and rpath per generator
2011/2/15 Daryl N darylhouse2...@yahoo.com:
Hi,
I have a question on the use of CPack. I have CMake setup to generate
binaries and shared libraries. Up until now I have only created a TGZ
with
rpath set to .. This has worked nicely, but now I would like to create
a
Debian package for proper installation. I have added DEB to
CPACK_GENERATOR
and I've created my own cpack_config.cmake file. My goal is:
1. Run cmake/make package once and create the tar.gz file with all
exe/libs
in the root folder of the tar.gz file with rpath set to ..
2. Create new .deb package with exes in /usr/local/bin and libs in
/usr/local/lib. Alternatively, since files are private, all could be put
in
/usr/local/some folder.
I've attempted this by creating my own cpack_config.cmake file to try to
override some settings per generator. Some observations:
1. I've been unable to set the install(target DESTINATION) path per
generator in my cpack_config.cmake file. Whatever the variable is set to
when the install(...) is processed in the CMakeLists.txt file is what is
used for all generators. Just want to confirm changing this isn't an
option
per generator.
The above has prevented me from having my install lines like:
install(target DESTINATION ${BIN_PATH})
install(target DESTINATION ${LIB_PATH})
and then setting BIN_PATH to bin and LIB_PATH to lib for DEB, but setting
them to . for TGZ, since I can't change the variable in
.
I suppose cpack_config.cmake is your CPACK_PROJECT_CONFIG_FILE.
As far as I know you cannot change install rules on CPack generator
basis.
install rules belongs to CMakeLists.txt and they are evaluated at
CMake-time
(not CPack-time).
cpack_config.cmake is evaluated at CPack-time, i.e. when CPack runs.
You can do CPack-generator specific actions in this file.
(like setting CPACK_SET_DESTDIR OFF or ON or changing
CPACK_PACKAGING_INSTALL_PREFIX etc...)
I did not tried playing with rpath but may be you can
if(CPACK_GENERATOR MATCHES TGZ)
set(CMAKE_INSTALL_RPATH .)
set(CPACK_SET_DESTDIR OFF)
endif(CPACK_GENERATOR MATCHES TGZ)
if(CPACK_GENERATOR MATCHES DEB)
set(CPACK_PACKAGING_INSTALL_PREFIX /usr/local/somefolder)
endif(CPACK_GENERATOR MATCHES DEB)
2. I would also like to set the rpath per generator. So the targets in
the
TGZ only look in . while the DEB installed targets only look in
/usr/local/some folder. But I haven't been able to update the rpath
per
generator in cpack_config.cmake. I've tried both setting
CMAKE_INSTALL_RPATH and using set_target_properties(... PROPERTIES
INSTALL_RPATH). Again, I'm assuming this can't be changed at CPack time.
I don't know whether if CMAKE_INSTALL_RPATH can be changed at CPack time
(as I suggested in my previous example) you'll have to try and
may be verify in the CMake source code in order to check when it is
handled.
Whatever the current status,
I don't see why it couldn't be handled at CPack time
(but I may be missing something).
Do I need to run cpack
separately changing the variables before hand? I suppose that would mean
2
builds cycles also, once for each generator.
2 build cycles will definitely work.
However if you gives us more information on what's inside your
cpack_config.cmake
what works what does not work with it, may be we can see if it it can
be done in a single build.
I think the main issue
[CMake] detecting build configuration in Visual Studio
In MSVC I need to link different libraries depending on the chosen build type. I have two questions: 1) If and how can I register my own build types 2) How can I detect which one I am in for conditional linking Many thanks for any hints, Dominik ___ 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] Setting target destination and rpath per generator
2011/2/15 David Cole david.c...@kitware.com: You cannot do cmake-ish things in the CPACK_PROJECT_CONFIG_FILE. Neither install commands nor set_target_properties calls do anything in this context. Yes you are right, but we may have expected that CMAKE_INSTALL_RPATH may be used at INSTALL time just like CMAKE_INSTALL_DO_STRIP or CMAKE_INSTALL_PREFIX are. That said, current status is one needs to build twice for fulfilling the Daryl's needs. -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] mixed compilation with two compilers
I need to compile a few subprojects (each is a subfolder with one
library and a corresponding CMakeLists.txt) with the Intel compiler
while the rest of the libraries (organized the same way), including
the executable, using the system compiler (GNU on linux, VC on
Windows). I tried two solutions to no avail:
1) In the subfolder's CMakeLists.txt do like:
SET(CMAKE_CXX_COMPILER ${INTEL_CXX_COMPILER})
SET(CMAKE_CXX_FLAGS_DEBUG ${INTEL_CXX_FLAGS_DEBUG})
While this substitutes the CMAKE_CXX* variables correctly with
INTEL_CXX* ones (confirmed by MESSAGE) the actual compilation still
takes place using parent CMAKE_CXX_* variables. This is very
surprising as many other CMake commands respect the subfolder scope.
2) Properties. There is a way to have ADDITIONAL compile flags, but
not CUSTOM. There seems to be no property for the compiler itself.
The compilation has to be mixed, and no post-processing (like some
converting scripts) are allowed. Is this possible or this is a dead
end?
Best regards,
Dominik
___
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] mixed compilation with two compilers
You should use ExternalProject, and possibly wrapper scripts to set
environment variables for the projects that need to use the different
compiler. (CC, CXX, FC env vars should be set during the configure stage, or
you can pass them in as -D args to cmake)
CMake does not support changing the compiler in a sub-portion of the build
tree.
On Tue, Feb 15, 2011 at 11:23 AM, Dominik Szczerba domi...@itis.ethz.chwrote:
I need to compile a few subprojects (each is a subfolder with one
library and a corresponding CMakeLists.txt) with the Intel compiler
while the rest of the libraries (organized the same way), including
the executable, using the system compiler (GNU on linux, VC on
Windows). I tried two solutions to no avail:
1) In the subfolder's CMakeLists.txt do like:
SET(CMAKE_CXX_COMPILER ${INTEL_CXX_COMPILER})
SET(CMAKE_CXX_FLAGS_DEBUG ${INTEL_CXX_FLAGS_DEBUG})
While this substitutes the CMAKE_CXX* variables correctly with
INTEL_CXX* ones (confirmed by MESSAGE) the actual compilation still
takes place using parent CMAKE_CXX_* variables. This is very
surprising as many other CMake commands respect the subfolder scope.
2) Properties. There is a way to have ADDITIONAL compile flags, but
not CUSTOM. There seems to be no property for the compiler itself.
The compilation has to be mixed, and no post-processing (like some
converting scripts) are allowed. Is this possible or this is a dead
end?
Best regards,
Dominik
___
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] Include-Dir order problem
On 02/13/2011 01:27 AM, Andreas Pakulat wrote: Hi, I've got a somewhat tricky problem here with include directories. I'm building a couple of source files and for some of them I need to add an include-directory to the front of the list that cmake passes to the compiler. At the same time other source files in that directory need to not have that include-dir in front of the list. I can't see a way to do this, except by using COMPILE_FLAGS source file properties for each and every file to specify include-dirs and not use include_directories at all, as COMPILE_FLAGS always end up behind the includes. So, am I missing something here? If not I guess I'll have to find that bugreport about making include-dirs a source-file property and vote for it so it gets included into 2.8.5... Currently, AFAIK, it's not possible to set source-file-specific include directories unless one (mis)uses COMPILE_FLAGS which is accompanied by the shortcoming you've mentioned. Probably, the really clean solution ATM would be a reorganisation of the sources, but I doubt if the need for different include directories is an appropriate criterion for a project's directory layout. If there're only a few affected files, another possible workaround consists of file-specific configured headers, i.e. find the special include directories and inject them into config'd headers that are included by the concerned source files, or even modify the latters themselves in this manner. Of course, the sources must be touched to do that. IMO, from a conceptual point of view, INCLUDE_DIRECTORIES should be also available as target and source file property, so I would vote for 1968 and 8189 - seem to be relatives - and possibly 8874, too. However, if this undertaking is addressed, one should think about how the include directories are ordered on the compiler's command line. Perhaps, there might be a convention that they appear from most to least specific, i.e. in source-target-directory order. 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] cpack 32bit rpm on a 64bit system
Dear CMakers, I am trying to package a 32bit binary on a 64bit system. It breaks with the (useless?) verbose output which follows below. What I could find of useful information was in _CPack_Packages/Linux/RPM/rpmbuild.err, which stated error: No compatible architectures found for build I tried to set CPACK_RPM_PACKAGE_ARCHITECTURE and CPACK_PACKAGE_ARCHITECTURE to i686, but that didn't do much. I found that e.g. the TGZ generator works just fine, so I suppose it is something with the RPM generator, but I am not clever enough to figure out what... Can anyone help? Cheers and thanks, Yngve cpack -V -G RPM CPack: Enable Verbse CPack Verbose: Read CPack config file: CPack Verbose: Read CPack configuration file: /path/to/build/CPackConfig.cmake CPack Verbose: Specified generator: RPM CPack Verbose: Use generator: cmCPackRPMGenerator CPack Verbose: For project: madX CPack: Create package using RPM CPack Verbose: Read description file: /usr/share/cmake/Templates/CPack.GenericDescription.txt CPack Verbose: Remove toplevel directory: /path/to/build/_CPack_Packages/Linux/RPM CPack: Install projects CPack: - Run preinstall target for: madX CPack: - Install project: madX CPack Verbose: Install configuration: Release CPack Verbose: Installing: /path/to/build/_CPack_Packages/Linux/RPM/madX-4.01.45-Linux/usr/bin/madx_dev CPack Verbose: Installing: /path/to/build/_CPack_Packages/Linux/RPM/madX-4.01.45-Linux/usr/include/madX/fortran_wrappers.h CPack: Compress package CPack Verbose: Compress files to: /path/to/build/_CPack_Packages/Linux/RPM/madX-4.01.45-Linux.rpm CPack: Finalize package CPack Verbose: Copy final package: /path/to/build/_CPack_Packages/Linux/RPM/madX-4.01.45-Linux.rpm to /path/to/build/madX-4.01.45-Linux.rpm CPack Error: Problem copying the package: /path/to/build/_CPack_Packages/Linux/RPM/madX-4.01.45-Linux.rpm to /path/to/build/madX-4.01.45-Linux.rpm CPack Error: Error when generating package: madX ___ 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] add_executable(...) with source from another path
Hello guys, I'm new to CMake and I'm really enjoying it. Anyway.. I'm porting a gnu makefile project to CMake and I need to compile 3 sources code to generate one executable. What's the better way to do that with CMake? Thank you ___ 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] FIND_PATH issue in FindQt4.cmake
On 15.02.11 06:34:07, Harinarayan Krishnan wrote: Hi All, Thanks for the help so far, I will check and see if CMake 2.8.4rc has the same issue meanwhile I noticed that FIND_PATH seems to have special instructions for Darwin machines with the use of CMAKE_FIND_FRAMEWORK on page http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_path The notes are a little confusing: it says CMAKE_FIND_FRAMEWORK defaults to FIRST on Darwin systems which I can interpret one of two ways. First, If a standard library and a framework are found in the same search order then CMAKE will use this variable to determine which to pick first. Second, if a framework is found regardless of where it is in the search order it will be picked. I suspect the choice is the first one. However, in my test I found that if I set CMAKE_FIND_FRAMEWORK to be LAST then CMAKE picks the proper path. This would make me think the second option is at play or it is just pure coincidence that this option happened to give me the correct result. Any of you know what the correct option is? To me it would make sense that FIND_PATH honors the search order which would mean that the HINTS option in FindQt4 should have higher precedence than the Framework in the CMAKE_SYSTEM_FRAMEWORK_PATH. This cannot be answered without looking at the source code (as its not documented properly) to check what exactly the algorithm does. That is wether it iterates of the individual path in each of the steps and then checks for framework and afterwards for standard headers in that path or if it first checks all paths in a step for frameworks and then again checks all paths for standard headers. Depending on which of the two it is, the outcome of a find_path may depend on the order of the input path-variables (like CMAKE_PREFIX_PATH) or not. Andreas -- You are the only person to ever get this message. ___ 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] Include-Dir order problem
On 15.02.11 17:54:29, Michael Hertling wrote: On 02/13/2011 01:27 AM, Andreas Pakulat wrote: Hi, I've got a somewhat tricky problem here with include directories. I'm building a couple of source files and for some of them I need to add an include-directory to the front of the list that cmake passes to the compiler. At the same time other source files in that directory need to not have that include-dir in front of the list. I can't see a way to do this, except by using COMPILE_FLAGS source file properties for each and every file to specify include-dirs and not use include_directories at all, as COMPILE_FLAGS always end up behind the includes. So, am I missing something here? If not I guess I'll have to find that bugreport about making include-dirs a source-file property and vote for it so it gets included into 2.8.5... Currently, AFAIK, it's not possible to set source-file-specific include directories unless one (mis)uses COMPILE_FLAGS which is accompanied by the shortcoming you've mentioned. Probably, the really clean solution ATM would be a reorganisation of the sources, but I doubt if the need for different include directories is an appropriate criterion for a project's directory layout. Well, all those sources need to be in the same target, so I can't quite see how moving some of the sources into subdirs wuld help with that. If there're only a few affected files, another possible workaround consists of file-specific configured headers, i.e. find the special include directories and inject them into config'd headers that are included by the concerned source files, or even modify the latters themselves in this manner. Of course, the sources must be touched to do that. Thats probably the route I'm going to take as indeed there are only few files needing the extra include at the front and it'll also solve the problem of new developers in the team not realizing that the header that is included is not the one they think it is... IMO, from a conceptual point of view, INCLUDE_DIRECTORIES should be also available as target and source file property, so I would vote for 1968 and 8189 - seem to be relatives - and possibly 8874, too. However, if this undertaking is addressed, one should think about how the include directories are ordered on the compiler's command line. Perhaps, there might be a convention that they appear from most to least specific, i.e. in source-target-directory order. Thanks for digging up the bugnumbers for me. I've added my use-case there and will make sure to bring this up when the cmake devs gather input again for the next release... Andreas -- You will soon meet a person who will play an important role in your life. ___ 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] FIND_PATH issue in FindQt4.cmake
Hi All,
I reran my code using cmake 2.8.4rc and still get the same issue where
FIND_PATH is picking the system directory for QT_CORE over my install
directory passed through HINTS ${qt_headers}. If this is not related to
CMAKE_FIND_FRAMEWORK should I file a bug report on this?
Thanks,
Hari
On Tue, Feb 15, 2011 at 10:23 AM, Andreas Pakulat ap...@gmx.de wrote:
On 15.02.11 06:34:07, Harinarayan Krishnan wrote:
Hi All,
Thanks for the help so far, I will check and see if CMake 2.8.4rc has the
same issue meanwhile I noticed that FIND_PATH seems to have special
instructions for Darwin machines with the use of CMAKE_FIND_FRAMEWORK on
page
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_path
The notes are a little confusing: it says CMAKE_FIND_FRAMEWORK defaults
to
FIRST on Darwin systems which I can interpret one of two ways.
First, If a standard library and a framework are found in the same search
order then CMAKE will use this variable to determine which to pick first.
Second, if a framework is found regardless of where it is in the search
order it will be picked. I suspect the choice is the first one. However,
in
my test I found that if I set CMAKE_FIND_FRAMEWORK to be LAST then
CMAKE
picks the proper path. This would make me think the second option is at
play
or it is just pure coincidence that this option happened to give me the
correct result.
Any of you know what the correct option is? To me it would make sense
that
FIND_PATH honors the search order which would mean that the HINTS option
in
FindQt4 should have higher precedence than the Framework in the
CMAKE_SYSTEM_FRAMEWORK_PATH.
This cannot be answered without looking at the source code (as its not
documented properly) to check what exactly the algorithm does. That is
wether it iterates of the individual path in each of the steps and then
checks for framework and afterwards for standard headers in that path or
if it first checks all paths in a step for frameworks and then again
checks all paths for standard headers. Depending on which of the two it
is, the outcome of a find_path may depend on the order of the input
path-variables (like CMAKE_PREFIX_PATH) or not.
Andreas
--
You are the only person to ever get this message.
___
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] cpack 32bit rpm on a 64bit system
2011/2/15 Yngve Inntjore Levinsen yngve.levin...@gmail.com: Dear CMakers, I am trying to package a 32bit binary on a 64bit system. It breaks with the (useless?) verbose output which follows below. What I could find of useful information was in _CPack_Packages/Linux/RPM/rpmbuild.err, which stated error: No compatible architectures found for build Which version of CMake/CPack ? I tried to set CPACK_RPM_PACKAGE_ARCHITECTURE and CPACK_PACKAGE_ARCHITECTURE to i686, but that didn't do much. I found that e.g. the TGZ generator works just fine, so I suppose it is something with the RPM generator, but I am not clever enough to figure out what... Can anyone help? Could you send me the log obtained with: cpack -V -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM and send me the advertised rpmbuild.err, rpmbuild.out, yourpackageName.spec files? Some more questions: What is your linux distribution ? How did you build the 32bits binaries with CMake (? add -m32 using CFLAGS?) ? RPM packaging of 32bits apps on 64bits may not be portable at all, why are you trying to do that ? -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] add_executable(...) with source from another path
On 2011-02-15 16:06-0200 Felipe Ferreri Tonello wrote:
Hello guys,
I'm new to CMake and I'm really enjoying it. Anyway.. I'm porting a gnu
makefile project to CMake and I need to compile 3 sources code to generate one
executable.
What's the better way to do that with CMake?
Use the full pathname for each src file. The predefined variable
${CMAKE_SOURCE_DIR} (see
http://www.cmake.org/Wiki/CMake_Useful_Variables) which points to the
top of the source tree is a big help here.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
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] Simple (?) problem with libraries executable dependencies
On Tuesday 15 February 2011, Carminati Federico wrote:
Hello Michael,
thanks a lot for looking into my problem. It turns out that Mac OS X
behaves a bit oddly, in the sense that the name of the directory of
installation is in the libraries as well as in the executable. I solved the
problem with a single line setting the properties of the library in the
following way:
set_target_properties(${PACKAGE} PROPERTIES INSTALL_NAME_DIR
${CMAKE_LIBRARY_OUTPUT_DIRECTORY})
That doesn't look right.
CMAKE_LIBRARY_OUTPUT_DIRECTORY is the directory where the library is built,
not the directory where it is installed to.
Is libMUONevaluation.so actually getting installed or is that an old version
which is already in /usr/local ?
Maybe it is not and the executable doesn't find it then, because it has not
been installed ?
Also, I thought on OSX it's DYLD_LIBRARY_PATH, and not LD_LIBRARY_PATH. AFAIK
you also don't have an RPATH, but instead INSTALL_NAME_DIR.
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
Re: [CMake] 2.8.5 version
On Monday 14 February 2011, David Cole wrote: On Mon, Feb 14, 2011 at 4:14 AM, Andrea Galeazzi galea...@korg.it wrote: I'm very interested in the feature discussed here: http://www.mail-archive.com/cmake@cmake.org/msg34587.html but probably it won't enter into 2.8.4, so do you have any rough idea about when 2.8.5 will be released? Or better, do you have a periodic schedule planning the releases? You are correct. We will be releasing 2.8.4 very shortly... We are now aiming for quarterly releases of CMake, so I expect that 2.8.5 will be released in May, 2011. We'll probably schedule a release candidate 1 trial build for late April. I have a local fix for the mentioned issue, but I thought I should not try to merge it now into next, since it is more like a feature and less like a bugfix. But I can do it you you#re ok with it. 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
Re: [CMake] Cross compilation question
On Monday 14 February 2011, Steven Wilson wrote: My apologies if this question has been asked and answered previously.I have a CMake system that I use for cross compilation for iOS software (ie reset CMAKE_C_COMPILER, etc...). How do you do that ? You have to set CMAKE_C_COMPILER, CMAKE_CXX_COMPILER and CMAKE_SYSTEM_NAME. And they have to be set so that they stay the same later on, e.g. by using a toolchain file. Do you do it that way or in some other way ? Do you use the makefile generator or xcode ? 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
Re: [CMake] Setting target destination and rpath per generator
On Tuesday 15 February 2011, Daryl N wrote:
Hi,
I have a question on the use of CPack. I have CMake setup to generate
binaries and shared libraries. Up until now I have only created a TGZ with
rpath set to .. This has worked nicely, but now I would like to create a
Debian package for proper installation. I have added DEB to
CPACK_GENERATOR and I've created my own cpack_config.cmake file. My goal
is:
1. Run cmake/make package once and create the tar.gz file with all exe/libs
in the root folder of the tar.gz file with rpath set to ..
2. Create new .deb package with exes in /usr/local/bin and libs in
/usr/local/lib. Alternatively, since files are private, all could be put
in /usr/local/some folder.
I've attempted this by creating my own cpack_config.cmake file to try to
override some settings per generator. Some observations:
1. I've been unable to set the install(target DESTINATION) path per
generator in my cpack_config.cmake file. Whatever the variable is set to
when the install(...) is processed in the CMakeLists.txt file is what is
used for all generators. Just want to confirm changing this isn't an
option per generator.
The above has prevented me from having my install lines like:
install(target DESTINATION ${BIN_PATH})
install(target DESTINATION ${LIB_PATH})
and then setting BIN_PATH to bin and LIB_PATH to lib for DEB, but setting
them to . for TGZ, since I can't change the variable in
cpack_config.cmake.
Are you sure . does what you want ? I can remember I tried it to, and didn't
what I needed, but I can't remember the details.
Do you know about $ORIGIN for the RPATH ? This means the location of the
containing ELF file.
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
Re: [CMake] 2.8.5 version
2011/2/15 Alexander Neundorf a.neundorf-w...@gmx.net On Monday 14 February 2011, David Cole wrote: On Mon, Feb 14, 2011 at 4:14 AM, Andrea Galeazzi galea...@korg.it wrote: I'm very interested in the feature discussed here: http://www.mail-archive.com/cmake@cmake.org/msg34587.html but probably it won't enter into 2.8.4, so do you have any rough idea about when 2.8.5 will be released? Or better, do you have a periodic schedule planning the releases? You are correct. We will be releasing 2.8.4 very shortly... We are now aiming for quarterly releases of CMake, so I expect that 2.8.5 will be released in May, 2011. We'll probably schedule a release candidate 1 trial build for late April. I have a local fix for the mentioned issue, but I thought I should not try to merge it now into next, since it is more like a feature and less like a bugfix. But I can do it you you#re ok with it. Alex You can push to the stage and merge to next whenever you like. That's one of the beauties of our new git workflow... ___ 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] Naive (stupid?) question
Hello, apologies for the stupid question. I have a large project and at times a change triggers unexpected consequences, i.e. very large recompilations, rebuild of the cmake makefiles and so on. Is there a way in cmake to understand why things happens? I mean which chain of dependencies causes a given action to be taken? It would be for me very interesting to understand something more about the dependencies in my project, to be able to reduce them. Thanks and best regards, Federico Carminati CERN-PH 1211 Geneva 23 Switzerland Tel: +41 22 76 74959 Fax: +41 22 76 68505 Mobile: +41 76 487 4843 ___ 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] Cross-compiling: Cmake compiler and ABI check don´t work
Hi, On Friday 11 February 2011, Schmid Alexander wrote: Hi, I am working with CMake 2.8.3 and trying to set up a cross-compiling toolchain for an ARMCC that runs on a Windows system. What I´ve done up to now is that I set up a toolchain file that I am using in combination with nmake makefiles. Can you please post the complete toolchain file ? Maybe there's something unusual in it. 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
Re: [CMake] Cross compilation question
In my CMake configuration files I have something like the following: if(SYSTEM STREQUAL iOS) set(CMAKE_C_COMPILER foo CACHE STRING message FORCE) set(CMAKE_CXX_COMPILER bar CACHE STRING message FORCE) endif(SYSTEM STREQUAL iOS) Then when configuring the system I pass -DSYSTEM:STRING=iOS on the command line (or through a GUI). For my iOS system I use the makefile generator. Steve 2011/2/15 Alexander Neundorf a.neundorf-w...@gmx.net On Monday 14 February 2011, Steven Wilson wrote: My apologies if this question has been asked and answered previously. I have a CMake system that I use for cross compilation for iOS software (ie reset CMAKE_C_COMPILER, etc...). How do you do that ? You have to set CMAKE_C_COMPILER, CMAKE_CXX_COMPILER and CMAKE_SYSTEM_NAME. And they have to be set so that they stay the same later on, e.g. by using a toolchain file. Do you do it that way or in some other way ? Do you use the makefile generator or xcode ? 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
Re: [CMake] Cross compilation question
On 15.02.2011 22:52, Steven Wilson wrote: In my CMake configuration files I have something like the following: if(SYSTEM STREQUAL iOS) set(CMAKE_C_COMPILER foo CACHE STRING message FORCE) set(CMAKE_CXX_COMPILER bar CACHE STRING message FORCE) endif(SYSTEM STREQUAL iOS) Do you know this wiki page: http://www.cmake.org/Wiki/CMake_Cross_Compiling I never had such problems you describe by writing a small toolchain file and initially pass it to cmake by -DCMAKE_TOOLCHAIN_FILE=... Later on I only call cmake . Peter ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CPack and OpenSSL libraries
Am using CPack to create Windows and Mac installers for an application. The application is Qt based, and BundleUtilities is working great for me to pick up dependencies and such. However, I have problem that OpenSSL libraries, which are needed for some segments of functionality of my app, are not picked up. I guess Qt network module is using these libraries as plugins, which means it is checking in run time are libraries present on the target system or not, and is loading them dynamically if so. I have no problems with my Mac installer in that regard, as it seems on Mac machines OpenSSL libraries are installed by default, so my application is able to pick them up at run time. However, for the Windows installer, I'll guess I'll have to pick them somehow. So I was just wondering has anyone encountered this problem so far, and what would be preferred solution with CMake/CPack (to utilize FindOpenSSL.cmake and then explicitly link my app with OpenSSL libraries, or maybe something else)? Thanks. ___ 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 and OpenSSL libraries
Download the latest ssl libs or which ever version you need. Then place them
in your QT libs dir (or any dir)and call it for install.
IF( WIN32 )
INSTALL(FILES
${CMAKE_CURRENT_SOURCE_DIR}/qtlibs/libeay32.DLL
${CMAKE_CURRENT_SOURCE_DIR}/vcredist/ssleay32.DLL
DESTINATION ${support_dest_dir}
COMPONENT Runtime
)
ENDIF( WIN32 )
--
View this message in context:
http://cmake.3232098.n2.nabble.com/CPack-and-OpenSSL-libraries-tp6029611p6029647.html
Sent from the CMake mailing list archive at Nabble.com.
___
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] Cross compilation question
I haven't done anything with toolchains. I will take a look at the page and give it a go. Thanks, Steve On Tue, Feb 15, 2011 at 3:16 PM, Peter Kümmel syntheti...@gmx.net wrote: On 15.02.2011 22:52, Steven Wilson wrote: In my CMake configuration files I have something like the following: if(SYSTEM STREQUAL iOS) set(CMAKE_C_COMPILER foo CACHE STRING message FORCE) set(CMAKE_CXX_COMPILER bar CACHE STRING message FORCE) endif(SYSTEM STREQUAL iOS) Do you know this wiki page: http://www.cmake.org/Wiki/CMake_Cross_Compiling I never had such problems you describe by writing a small toolchain file and initially pass it to cmake by -DCMAKE_TOOLCHAIN_FILE=... Later on I only call cmake . Peter ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ 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] Patch for watcom InstallRequiredSystemLibraries
http://public.kitware.com/Bug/view.php?id=11866 ___ 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] Setting target destination and rpath per generator
Thank you! I did not know about $ORIGIN but that is indeed exactly what I need.
From: Alexander Neundorf a.neundorf-w...@gmx.net
To: cmake@cmake.org
Cc: Daryl N darylhouse2...@yahoo.com
Sent: Tue, February 15, 2011 3:45:25 PM
Subject: Re: [CMake] Setting target destination and rpath per generator
On Tuesday 15 February 2011, Daryl N wrote:
Hi,
I have a question on the use of CPack. I have CMake setup to generate
binaries and shared libraries. Up until now I have only created a TGZ with
rpath set to .. This has worked nicely, but now I would like to create a
Debian package for proper installation. I have added DEB to
CPACK_GENERATOR and I've created my own cpack_config.cmake file. My goal
is:
1. Run cmake/make package once and create the tar.gz file with all exe/libs
in the root folder of the tar.gz file with rpath set to ..
2. Create new .deb package with exes in /usr/local/bin and libs in
/usr/local/lib. Alternatively, since files are private, all could be put
in /usr/local/some folder.
I've attempted this by creating my own cpack_config.cmake file to try to
override some settings per generator. Some observations:
1. I've been unable to set the install(target DESTINATION) path per
generator in my cpack_config.cmake file. Whatever the variable is set to
when the install(...) is processed in the CMakeLists.txt file is what is
used for all generators. Just want to confirm changing this isn't an
option per generator.
The above has prevented me from having my install lines like:
install(target DESTINATION ${BIN_PATH})
install(target DESTINATION ${LIB_PATH})
and then setting BIN_PATH to bin and LIB_PATH to lib for DEB, but setting
them to . for TGZ, since I can't change the variable in
cpack_config.cmake.
Are you sure . does what you want ? I can remember I tried it to, and didn't
what I needed, but I can't remember the details.
Do you know about $ORIGIN for the RPATH ? This means the location of the
containing ELF file.
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
Re: [CMake] detecting build configuration in Visual Studio
On 02/15/2011 03:49 PM, Dominik Szczerba wrote:
In MSVC I need to link different libraries depending on the chosen
build type. I have two questions:
1) If and how can I register my own build types
http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_specify_my_own_configurations_.28for_generators_that_allow_it.29_.3F
2) How can I detect which one I am in for conditional linking
AFAIK, you can't, but you might do the following: Declare the differing
libraries for the different configurations as IMPORTED libraries and
set the IMPORTED_LOCATION_CONFIG properties accordingly, e.g.:
ADD_LIBRARY(xyz SHARED IMPORTED)
SET_TARGET_PROPERTIES(xyz PROPERTIES
IMPORTED_LOCATION_CUSTOMIZED ...
IMPORTED_LOCATION_RELEASE ...
IMPORTED_LOCATION_DEBUG ...
...
)
...
TARGET_LINK_LIBRARIES(... xyz ...)
If such a library should not be taken into account for a particular
configuration at all, things are more complex since you can't declare
an empty IMPORTED_LOCATION. A possible approach might look as follows:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(IMPORTEDDUMMY C)
ADD_LIBRARY(dummy STATIC )
SET_TARGET_PROPERTIES(dummy PROPERTIES LINKER_LANGUAGE C)
EXPORT(TARGETS dummy NAMESPACE imported FILE importeddummy.cmake)
INCLUDE(${CMAKE_BINARY_DIR}/importeddummy.cmake)
SET_TARGET_PROPERTIES(importeddummy PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_CUSTOMIZED ...
)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main importeddummy)
The target dummy is an empty static library and needed as anchor for
an imported static library importeddummy which refers to the former;
this is achieved by EXPORT() and the generated importeddummy.cmake
file. Finally, the importeddummy target is associated with additional
libraries via the IMPORTED_LINK_INTERFACE_LIBRARIES_CONFIG property.
This property is the reason for the intermediate importeddummy target
since it can't be imposed on non-imported ones. At the end of the day,
the additional libraries appear in the link command line only for the
CUSTOMIZED configuration. Maybe, it would be worth a feature request
to drop an imported library from the link command line completely if
there's no IMPORTED_LOCATION for the active configuration instead of
having make raise an error.
'hope that helps.
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] Include-Dir order problem
On 02/15/2011 07:36 PM, Andreas Pakulat wrote:
On 15.02.11 17:54:29, Michael Hertling wrote:
On 02/13/2011 01:27 AM, Andreas Pakulat wrote:
Hi,
I've got a somewhat tricky problem here with include directories. I'm
building a couple of source files and for some of them I need to add an
include-directory to the front of the list that cmake passes to the
compiler. At the same time other source files in that directory need to
not have that include-dir in front of the list.
I can't see a way to do this, except by using COMPILE_FLAGS source file
properties for each and every file to specify include-dirs and not use
include_directories at all, as COMPILE_FLAGS always end up behind the
includes.
So, am I missing something here? If not I guess I'll have to find that
bugreport about making include-dirs a source-file property and vote for
it so it gets included into 2.8.5...
Currently, AFAIK, it's not possible to set source-file-specific include
directories unless one (mis)uses COMPILE_FLAGS which is accompanied by
the shortcoming you've mentioned. Probably, the really clean solution
ATM would be a reorganisation of the sources, but I doubt if the need
for different include directories is an appropriate criterion for a
project's directory layout.
Well, all those sources need to be in the same target, so I can't quite
see how moving some of the sources into subdirs wuld help with that.
Look at the following CMakeLists.txt files:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(INCLUDEDIRECTORIES C)
ADD_SUBDIRECTORY(subdir)
INCLUDE_DIRECTORIES(abc)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){f();return 0;}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main sub)
# subdir/CMakeLists.txt:
INCLUDE_DIRECTORIES(xyz)
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(sub STATIC f.c)
So, main.c and f.c are compiled with different include directories, but
the main target is effectively composed from the same object files as
if f.c had been explicitly mentioned among the source files for main.
If you commute the ADD_SUBDIRECTORY() and INCLUDE_DIRECTORIES() commands
in the top-level CMakeLists.txt, the include directories for main.c will
also hold for f.c while the latter still has its own - additional - ones.
Things become worse if the target to be built is a shared library. Most
probably, you don't want an additional libsub.so, so you would need to
compile f.c at least with -fPIC as COMPILE_FLAGS to get further along
with a static library. Alternatively, you might use a RULE_LAUNCH_LINK
property in order to capture the object files from the subdirectory and
incorporate them in the actual target, see [1]. However, then you would
be restricted to a Makefile generator. IMO, none of these appoaches is
really convincing why one should aim at an INCLUDE_DIRECTORIES source
file and target property.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg34148.html
___
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 and OpenSSL libraries
Yeah, Qt uses them as plugins by default so BundleUtilities won't pick it up. You could also copy it manually like other Qt plugins, or configure Qt with the -openssl-link flag so it can copy the library for you. Clint - Reply message - From: Crni Gorac cgo...@gmail.com Date: Tue, Feb 15, 2011 3:38 pm Subject: [CMake] CPack and OpenSSL libraries To: cmake@cmake.org Am using CPack to create Windows and Mac installers for an application. The application is Qt based, and BundleUtilities is working great for me to pick up dependencies and such. However, I have problem that OpenSSL libraries, which are needed for some segments of functionality of my app, are not picked up. I guess Qt network module is using these libraries as plugins, which means it is checking in run time are libraries present on the target system or not, and is loading them dynamically if so. I have no problems with my Mac installer in that regard, as it seems on Mac machines OpenSSL libraries are installed by default, so my application is able to pick them up at run time. However, for the Windows installer, I'll guess I'll have to pick them somehow. So I was just wondering has anyone encountered this problem so far, and what would be preferred solution with CMake/CPack (to utilize FindOpenSSL.cmake and then explicitly link my app with OpenSSL libraries, or maybe something else)? Thanks. ___ 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] Include-Dir order problem
On 16.02.11 03:48:03, Michael Hertling wrote:
On 02/15/2011 07:36 PM, Andreas Pakulat wrote:
On 15.02.11 17:54:29, Michael Hertling wrote:
On 02/13/2011 01:27 AM, Andreas Pakulat wrote:
Hi,
I've got a somewhat tricky problem here with include directories. I'm
building a couple of source files and for some of them I need to add an
include-directory to the front of the list that cmake passes to the
compiler. At the same time other source files in that directory need to
not have that include-dir in front of the list.
I can't see a way to do this, except by using COMPILE_FLAGS source file
properties for each and every file to specify include-dirs and not use
include_directories at all, as COMPILE_FLAGS always end up behind the
includes.
So, am I missing something here? If not I guess I'll have to find that
bugreport about making include-dirs a source-file property and vote for
it so it gets included into 2.8.5...
Currently, AFAIK, it's not possible to set source-file-specific include
directories unless one (mis)uses COMPILE_FLAGS which is accompanied by
the shortcoming you've mentioned. Probably, the really clean solution
ATM would be a reorganisation of the sources, but I doubt if the need
for different include directories is an appropriate criterion for a
project's directory layout.
Well, all those sources need to be in the same target, so I can't quite
see how moving some of the sources into subdirs wuld help with that.
Look at the following CMakeLists.txt files:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(INCLUDEDIRECTORIES C)
ADD_SUBDIRECTORY(subdir)
INCLUDE_DIRECTORIES(abc)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){f();return 0;}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main sub)
# subdir/CMakeLists.txt:
INCLUDE_DIRECTORIES(xyz)
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(sub STATIC f.c)
So, main.c and f.c are compiled with different include directories, but
the main target is effectively composed from the same object files as
if f.c had been explicitly mentioned among the source files for main.
If you commute the ADD_SUBDIRECTORY() and INCLUDE_DIRECTORIES() commands
in the top-level CMakeLists.txt, the include directories for main.c will
also hold for f.c while the latter still has its own - additional - ones.
Things become worse if the target to be built is a shared library.
Exactly my case.
Most probably, you don't want an additional libsub.so, so you would
need to compile f.c at least with -fPIC as COMPILE_FLAGS to get
further along with a static library. Alternatively, you might use a
RULE_LAUNCH_LINK property in order to capture the object files from
the subdirectory and incorporate them in the actual target, see [1].
However, then you would be restricted to a Makefile generator. IMO,
none of these appoaches is really convincing why one should aim at an
INCLUDE_DIRECTORIES source file and target property.
Unfortunately it seems Brad is unwilling to implement this unless it can
be done 'properly' for all generators. Which is sad, but for now I could
solve this with local special header files which are used by those cpp
files that would otherwise need the extra directory in front.
Andreas
--
Your object is to save the world, while still leading a pleasant life.
___
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.3-1633-g1971ff8
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 1971ff89d3cb44b2dd0361be18f10d8b1198cd8b (commit)
via acd8161bad5d2106f176cd464819df5fbedf2ec7 (commit)
from 236eab5e3732e3bfbf51a8983bb123203fe9dd18 (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=1971ff89d3cb44b2dd0361be18f10d8b1198cd8b
commit 1971ff89d3cb44b2dd0361be18f10d8b1198cd8b
Merge: 236eab5 acd8161
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Feb 15 08:52:51 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Feb 15 08:52:51 2011 -0500
Merge topic 'fix-clang-warnings' into next
acd8161 ccmake: Remove extra parens around comparison
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=acd8161bad5d2106f176cd464819df5fbedf2ec7
commit acd8161bad5d2106f176cd464819df5fbedf2ec7
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Feb 15 08:46:50 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Feb 15 08:46:50 2011 -0500
ccmake: Remove extra parens around comparison
The Clang compiler warns about extra parenthesis in the code
if ((form-curpage == field-page))
~ ^ ~
because the idiom is commonly used when an assignment is intended
instead of a comparison. Remove the extra enclosing layer.
diff --git a/Source/CursesDialog/form/frm_driver.c
b/Source/CursesDialog/form/frm_driver.c
index 03896c2..f234722 100644
--- a/Source/CursesDialog/form/frm_driver.c
+++ b/Source/CursesDialog/form/frm_driver.c
@@ -1086,7 +1086,7 @@ _nc_Synchronize_Options(FIELD *field, Field_Options
newopts)
if (form-status _POSTED)
{
- if ((form-curpage == field-page))
+ if (form-curpage == field-page)
{
if (changed_opts O_VISIBLE)
{
---
Summary of changes:
Source/CursesDialog/form/frm_driver.c |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, master, updated. v2.8.3-729-g4d1240e
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 4d1240eb0a8d0f867d7e15fe63fc6389ea550e60 (commit) via 1bb4c7be11b2fb7a19aeedfffdbb341553aae9d2 (commit) via d5d661d2b259447edfc89d130878f3a9b2203ea1 (commit) via 086cd2fa400cbfc1b5700cc3a322a66530ba3b84 (commit) via 37f4a1d121e9bdaa7e448fa8d7f4a7593434dd07 (commit) via 799efb4a2c173e44ae228658f2f00ade4778 (commit) from d4884710a4db8a24e08b47617c912ba83deb1e39 (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 - --- Summary of changes: CMakeLists.txt |2 +- ChangeLog.manual | 413 ++ 2 files changed, 414 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.3-1640-g48ca593
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 48ca59315cde4736edf364b887b9f92e56139eb8 (commit) via 4d1240eb0a8d0f867d7e15fe63fc6389ea550e60 (commit) via 1bb4c7be11b2fb7a19aeedfffdbb341553aae9d2 (commit) via d5d661d2b259447edfc89d130878f3a9b2203ea1 (commit) via 086cd2fa400cbfc1b5700cc3a322a66530ba3b84 (commit) via 37f4a1d121e9bdaa7e448fa8d7f4a7593434dd07 (commit) via 799efb4a2c173e44ae228658f2f00ade4778 (commit) from 1971ff89d3cb44b2dd0361be18f10d8b1198cd8b (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=48ca59315cde4736edf364b887b9f92e56139eb8 commit 48ca59315cde4736edf364b887b9f92e56139eb8 Merge: 1971ff8 4d1240e Author: David Cole david.c...@kitware.com AuthorDate: Tue Feb 15 11:46:58 2011 -0500 Commit: David Cole david.c...@kitware.com CommitDate: Tue Feb 15 11:46:58 2011 -0500 Merge branch 'master' into next --- Summary of changes: CMakeLists.txt |2 +- ChangeLog.manual | 413 ++ 2 files changed, 414 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, release, updated. v2.8.3-728-g1bb4c7b
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, release has been updated via 1bb4c7be11b2fb7a19aeedfffdbb341553aae9d2 (commit) via d5d661d2b259447edfc89d130878f3a9b2203ea1 (commit) via d4884710a4db8a24e08b47617c912ba83deb1e39 (commit) via 6720f97d3b07f89af283024d29fad2194edd06f7 (commit) via d02519e974c64805b7d193eb35b703a53beaa470 (commit) via 42a5e8d978a316620027b32eeb976a5b8758d8ba (commit) via 2a2fca24aa0058bb12f20d3d860c23123f902b74 (commit) via d26ef5c1180835d8cb32b1783b6e01806905b1e8 (commit) via 84dafee565cd49fd26b2018f82059ad5eed99cb1 (commit) via 831c5ebe581e4b5cc0dfb02c6f5e8ef4e955492f (commit) via bff5772084392d74aa3eb04188af4abb82c3ab21 (commit) via 5cdd05bc685b21911553fc3bd8d0b179501d9a2e (commit) via e53b7cbadf1b7faf353e91b6041a697a90d9584d (commit) via 7258b0674cf64292751dcd36d734688031fffa4c (commit) via ee55a4f70906a41db18df07de89383f0aa948c71 (commit) via d5fceb4f07108071f4899e2b1bdfb945615e84e2 (commit) via 7f87205161bb7d87b20e37b58079a8fab3d27640 (commit) via 5b8869faea87187743b7a1578f29b5c3223fee19 (commit) via 68c004aa11e2a6e16ebbd20f954e0299a31c8d56 (commit) via 41b7b3efa4e2684085be7c7dd76baea17f269988 (commit) via d7a51814a3886d99e8191183b21cb17198c05d34 (commit) via f97a1c6493770c2a17923a0696c4bac08284271b (commit) via d27dfc25c11516f775255dc1b4ff6eaf8df42eb5 (commit) via 00e7ea76e83153db1f95289a4b101b3031c97b99 (commit) via aa78a60ca65b37472a6cb217a269ebd5e1a37b6e (commit) via c310450daf346aafe1e9b230752952228a7e7815 (commit) via 26eba9cb9c1cbdc7739a9a26aeb4b8f00802f56d (commit) via bd7dd34aba1d4d9bf0dce6465e1fbc14ace321f8 (commit) via 4f1e1fe7821da7d5af17d18f031f72daa05c89e1 (commit) via b8da1a1378a4e36d80bda0cd551cb27dcb0ec982 (commit) via 92ced20fa13cd2b4ed45a80d265a590d2291f8ee (commit) from 086cd2fa400cbfc1b5700cc3a322a66530ba3b84 (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 - --- Summary of changes: CMakeLists.txt |2 +- ChangeLog.manual | 20 +++ Modules/FindPerlLibs.cmake |1 + Source/CPack/cmCPackOSXX11Generator.cxx|2 +- Source/CPack/cmCPackPackageMakerGenerator.cxx |2 +- Source/cmDocumentVariables.cxx | 10 +++- Source/cmGraphVizWriter.cxx|6 ++ Source/kwsys/kwsysDateStamp.cmake |4 +- Tests/CMakeLists.txt | 56 Tests/CPackComponentsForAll/CMakeLists.txt | 12 ++-- .../MyLibCPackConfig-AllGroupsInOne.cmake.in | 18 ++ .../MyLibCPackConfig-AllInOne.cmake.in | 18 ++ .../MyLibCPackConfig-IgnoreGroup.cmake.in | 18 ++ .../MyLibCPackConfig-OnePackPerGroup.cmake.in | 18 ++ .../MyLibCPackConfig.cmake.in |7 --- .../RunCPackVerifyResult.cmake | 12 Utilities/cmlibarchive/CMakeLists.txt | 12 - Utilities/cmlibarchive/libarchive/archive_entry.c | 15 -- .../cmlibarchive/libarchive/archive_entry_xattr.c |7 --- .../cmlibarchive/libarchive/archive_windows.h |5 -- 20 files changed, 184 insertions(+), 61 deletions(-) create mode 100644 Tests/CPackComponentsForAll/MyLibCPackConfig-AllGroupsInOne.cmake.in create mode 100644 Tests/CPackComponentsForAll/MyLibCPackConfig-AllInOne.cmake.in create mode 100644 Tests/CPackComponentsForAll/MyLibCPackConfig-IgnoreGroup.cmake.in create mode 100644 Tests/CPackComponentsForAll/MyLibCPackConfig-OnePackPerGroup.cmake.in delete mode 100644 Tests/CPackComponentsForAll/MyLibCPackConfig.cmake.in 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.3-1645-g6707097
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 670709703faf6388ab3096bf43c3221ee2a6e838 (commit) via 0cf1d72e3c1be9218f4dc0d1dcc0aaf03f160684 (commit) from 43d96cfe881eed354414195938deaefa537749e5 (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=670709703faf6388ab3096bf43c3221ee2a6e838 commit 670709703faf6388ab3096bf43c3221ee2a6e838 Merge: 43d96cf 0cf1d72 Author: Eric Noulard eric.noul...@gmail.com AuthorDate: Tue Feb 15 14:00:22 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Feb 15 14:00:22 2011 -0500 Merge topic 'CPackRPM-HonorAllComponentWays' into next 0cf1d72 CPackRPM fix IRIX compiler warning (variable never used) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0cf1d72e3c1be9218f4dc0d1dcc0aaf03f160684 commit 0cf1d72e3c1be9218f4dc0d1dcc0aaf03f160684 Author: Eric NOULARD eric.noul...@gmail.com AuthorDate: Tue Feb 15 19:55:36 2011 +0100 Commit: Eric NOULARD eric.noul...@gmail.com CommitDate: Tue Feb 15 19:55:36 2011 +0100 CPackRPM fix IRIX compiler warning (variable never used) diff --git a/Source/CPack/cmCPackRPMGenerator.cxx b/Source/CPack/cmCPackRPMGenerator.cxx index a5a9753..2d675c1 100644 --- a/Source/CPack/cmCPackRPMGenerator.cxx +++ b/Source/CPack/cmCPackRPMGenerator.cxx @@ -182,7 +182,7 @@ int cmCPackRPMGenerator::PackageComponentsAllInOne(bool allComponent) // add the generated package to package file names list packageFileNames.push_back(packageFileName); - return 1; + return retval; } //-- --- Summary of changes: Source/CPack/cmCPackRPMGenerator.cxx |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, master, updated. v2.8.3-730-g8caed60
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 8caed602080c6e052adec1d38dba8a37d3a76f58 (commit) from 4d1240eb0a8d0f867d7e15fe63fc6389ea550e60 (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=8caed602080c6e052adec1d38dba8a37d3a76f58 commit 8caed602080c6e052adec1d38dba8a37d3a76f58 Author: KWSys Robot kwro...@kitware.com AuthorDate: Wed Feb 16 00:01:10 2011 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Wed Feb 16 00:12:03 2011 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 2fc5086..1bcbf98 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 02) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 15) +SET(KWSYS_DATE_STAMP_DAY 16) --- 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
