Re: [cmake-developers] Volunteering to fix and commit some CPackDEB bugs
Eric, You have my blessing, if this was your question. Thanks ! On Sun, Jul 25, 2010 at 7:25 PM, Eric Noulard eric.noul...@gmail.com wrote: Hi All, Some CPack DEB generator related bugs are pending: http://public.kitware.com/Bug/view.php?id=10292 (with patches) http://public.kitware.com/Bug/view.php?id=10296 (with patch) http://public.kitware.com/Bug/view.php?id=10325 http://public.kitware.com/Bug/view.php?id=8790 (with patch) = Assigned to Mathieu I may have some spare time this week in order to handle some of them. Shall I go on and (re)assign some of those bugs to myself and commit the validated fix to next? Like I just answered to Alex on CMake-ML I do have commit right (granted for CPackRPM) but I don't want to abuse it. Since the way of work is somehow different with git than with CVS (when I was given commit right for CPackRPM) is it acceptable to self-assign ?any? bug and commit the fix to next without requesting permission first? May be this would be acceptable for the area with limited side effect? I mean fixing a bug of a single CPack generator looks ok, whereas modifying the CPack generator obviously needs discussion. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Mathieu ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] FindBoost : 1.42
Hi there, Before the next release, could someone please update FindBoost to search for 1.42. Thanks -- Mathieu ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] cmake generators on windows: nmake versus jom
Hi Alex, Will this do? http://www.cmake.org/Wiki/CMake_Generator_Specific_Information#Makefile_generators Regards, Arjen -Original Message- From: Alexander Neundorf [mailto:a.neundorf-w...@gmx.net] Sent: zondag 25 juli 2010 19:09 To: cmake@cmake.org Cc: Verweij, Arjen; Brad King Subject: Re: [CMake] cmake generators on windows: nmake versus jom On Thursday 22 July 2010, Verweij, Arjen wrote: Brad, I found another repository with jom binaries. It works fine with 0.9.4. Apparently the original link I used to download JOM was ancient. Here ( http://www.cmake.org/Wiki/CMake_Generator_Specific_Information#Makefile_ generators ) is some documentation about the available generators. Feel free to add some notes about the jom generator there :-) It's a wiki, you can simply get a login. 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] Problem with current CVS HEAD for creating ZIP with shared lib on Linux
2010/1/19 Eric Noulard eric.noul...@gmail.com: 2010/1/19 Bill Hoffman bill.hoff...@kitware.com: You should file a bug. This most likely is because we switched to libarchive for creation of the tar and zip files. Done: http://public.kitware.com/Bug/view.php?id=10162 Small update, I have just updated the bug (and unassigned it) since it looks like this is currently a libarchive limitation concerning the zip format. libarchive zip handling cannot handle symbolic links, tar is OK. -- 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] set a build dependence on an out of tree library
Hi everyone, I am new to cmake, tell me if completely wrong about the way to do. I have the following source tree : . ├── algorithms/ │ └── algo1/ │ ├── x.h │ ├── x.c │ └── algo2/ │ ├── y.h │ ├── y.c ├── library/ └── library.c └── liblibrary.a liblibrary.a is to be linked with algorithms algo1 and algo2. For now I have the following commands in the CMakeList.txt of each algox/ : add_library(library STATIC IMPORTED) set_property(TARGET library PROPERTY IMPORTED_LOCATION ../../library/liblibrary.a) I would like to set a dependency so whenever I compile algo1 or algo2 liblibrary.a is built. Can anyone give me a hint ? Ben. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Subdirectories and FIND_LIBRARY routines
Hi! I have a rather oddball question, and I'm not quite sure if I'm even asking the right question, but I'll describe the circumstances and see if it makes sense... I am trying to set up a CMake project which includes as subdirectories other CMake projects, but it does so only conditionally. I.e., I have: toplevel/ toplevel/libz toplevel/libpng and want to provide the user with the options to either: a) Use system libraries (disable the compilation and use of the local libz and libpng) b) Use local libraries (compile and use libz and libpng from local tree - libpng should also use the local libz in this situation) c) Use a mix of the two (system libz but local libpng, in this case libpng would use the system libz) I am getting the hang of setting variables using CACHE and FORCE options, and the VTK CMake files offer valuable hints, but I'm getting stuck on a detail. FindZLIB sets ZLIB_LIBRARY, and if I alter the configuration from local to system selection FindZLIB is run. All well and good, but if I switch back to local, the ZLIB_LIBRARY remains and remains set to the system lib. This raises two questions - if ZLIB_LIBRARY is set by FindZLIB, does it also need to be set when building the local libz (and if so, how, since libz is not built at configure time...) - also, since ZLIB_LIBRARY is now set in the cache by FIND_LIBRARY, what mechanism can I use to override that value with the local settings? Presumably I can't point FIND_LIBRARY at libz when it's not built yet and expect ZLIB_LIBRARY to get set, and even if I could would FIND_LIBRARY override and reset the cache settings? I've tried poking around various websites and wikis, and I apologize if I missed a tutorial covering these points. (For those of you thinking it, I've already lost the argument against any sort of local libz copy... the policy is that the option needs to be there). Autotools allows subconfigures, but the process has never been all that robust as most projects don't write their files with the notion of being a subconfigure in mind. I'm hoping CMake might provide a more robust solution to this issue? Thanks, CY ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Debug/Release configurations for codeblocks ?
I think it's a little strange to have multiple project file to manage one
project it multiple configurations, instead of having a single project file
for one project, that manages multiple configurations directly, isn't
codeblocks made for that ?
2010/7/25 Alexander Neundorf a.neundorf-w...@gmx.net
On Thursday 22 July 2010, Carlos wrote:
Hello,
It seems the debug/release default configuration are only built for
VStudio
suites.
Anyway I am trying to simulated such for the codeblocks IDE, this is how
I
did my CMakeLists.txt :
project( myapp )
add_executable( Release WIN32 ${my_src_files} )
target_link_libraries( Release ${my_libs} )
set_target_properties( Release PROPERTIES OUTPUT_NAME myappname )
add_executable( Debug ${my_src_files} )
target_link_libraries( Debug ${my_libs_dbg} )
set_source_files_properties( Debug PROPERTIES COMPILE_DEFINITIONS
etc
)
set_target_properties( Debug PROPERTIES OUTPUT_NAME myappname_dbg
etc
)
Actually this works pretty fine but :
Is that the right way to simulate VS build configurations ?
Hmm, the Codeblocks generator is makefile-based.
Each makefile-based buildtree builds only one configuration.
If you want multiple configurations, create one buildtree for each
configuration (each with its own C::B project file).
Is there any chance this conflicts with the VS generator ?
Other misc question :
What are the xxx/fast configurations in codeblocks ?
They are for building the respective target, but without checking whether
the
dependent targets are up-to-date (i.e. if you build A and A links against
B, A/fast will only check what needs to be built for A, but not check all
source files of B whether they have to be rebuild. This saves the time for
checking the dependencies).
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] Subdirectories and FIND_LIBRARY routines
On 26. Jul, 2010, at 17:59 , Clifford Yapp wrote:
Hi! I have a rather oddball question, and I'm not quite sure if I'm
even asking the right question, but I'll describe the circumstances
and see if it makes sense...
I am trying to set up a CMake project which includes as subdirectories
other CMake projects, but it does so only conditionally. I.e., I
have:
toplevel/
toplevel/libz
toplevel/libpng
and want to provide the user with the options to either:
a) Use system libraries (disable the compilation and use of the local
libz and libpng)
b) Use local libraries (compile and use libz and libpng from local
tree - libpng should also use the local libz in this situation)
c) Use a mix of the two (system libz but local libpng, in this case
libpng would use the system libz)
I am getting the hang of setting variables using CACHE and FORCE
options, and the VTK CMake files offer valuable hints, but I'm getting
stuck on a detail. FindZLIB sets ZLIB_LIBRARY, and if I alter the
configuration from local to system selection FindZLIB is run. All
well and good, but if I switch back to local, the ZLIB_LIBRARY remains
and remains set to the system lib. This raises two questions - if
ZLIB_LIBRARY is set by FindZLIB, does it also need to be set when
building the local libz (and if so, how, since libz is not built at
configure time...) - also, since ZLIB_LIBRARY is now set in the cache
by FIND_LIBRARY, what mechanism can I use to override that value with
the local settings? Presumably I can't point FIND_LIBRARY at libz
when it's not built yet and expect ZLIB_LIBRARY to get set, and even
if I could would FIND_LIBRARY override and reset the cache settings?
I've tried poking around various websites and wikis, and I apologize
if I missed a tutorial covering these points. (For those of you
thinking it, I've already lost the argument against any sort of local
libz copy... the policy is that the option needs to be there).
Autotools allows subconfigures, but the process has never been all
that robust as most projects don't write their files with the notion
of being a subconfigure in mind. I'm hoping CMake might provide a
more robust solution to this issue?
Thanks,
CY
Here's what I do:
# third-party library handling. if optional, generates an option
# ENABLE_upper_name (defaulting to enable) and if that is TRUE
# (or the package is not optional), generates an option
# BUILD_PRIVATE_upper_name whose default is determined by whether
# Findpkgname.cmake was successful. if that option is TRUE, the
# included package will be built, otherwise the system installation
# will be used.
macro(thirdparty_option name description
pkgname optional enable)
set(_tpo_name ${name})
set(_tpo_description ${description})
set(_tpo_pkgname ${pkgname})
set(_tpo_optional ${optional})
set(_tpo_enable ${enable})
string(TOUPPER ${_tpo_name} _tpo_upper_name)
string(TOUPPER ${_tpo_pkgname} _tpo_upper_pkgname)
if(_tpo_optional)
option(ENABLE_${_tpo_upper_name}
${_tpo_description} ${_tpo_enable})
mark_as_advanced(ENABLE_${_tpo_upper_name})
endif()
if(ENABLE_${_tpo_upper_name} OR NOT _tpo_optional)
find_package(${_tpo_pkgname} QUIET)
if(${_tpo_upper_pkgname}_FOUND)
set(_tpo_private OFF)
else()
set(_tpo_private ON)
endif()
option(BUILD_PRIVATE_${_tpo_upper_name}
Download and compile ${_tpo_name} instead of searching in on the system
${_tpo_private})
if(BUILD_PRIVATE_${_tpo_upper_name})
build_thirdparty(${_tpo_upper_name})
elseif(NOT ${_tpo_upper_pkgname}_FOUND)
# just to get the not-found-message on the screen
find_package(${_tpo_pkgname})
set(_tpo_msg
If you have ${_tpo_name} installed, edit the variables beginning
with ${_tpo_upper_name}_ to refer to the installation or enable the
setting BUILD_PRIVATE_${_tpo_upper_name} in the cache.\n
)
if(_tpo_optional)
message(SEND_ERROR
ENABLE_${_tpo_upper_name} is TRUE, but ${_tpo_name} cannot be
found. ${_tpo_msg}
)
else()
message(SEND_ERROR
${_tpo_name} is required but cannot be found.\n
${_tpo_msg}
)
endif()
else()
# just to get the found-message on the screen
find_package(${_tpo_pkgname})
endif()
mark_as_advanced(BUILD_PRIVATE_${_tpo_upper_name})
endif()
endmacro()
Where build_thirdparty() is a macro that builds the named package (in my case
through ExternalProject_Add) and sets compatibility variables (i.e. the
XXX_INCLUDE_DIR and XXX_LIBRARIES variables). This is possible since you can
always override the cached values of a variable (the reverse is undefined,
however. so be careful). Above code is intentionally a macro, since otherwise
it would be cumbersome to propagate the variables XXX_INCLUDE_DIR and
XXX_LIBRARIES (and similar ones) to the caller scope.
HTH
Michael
Re: [CMake] Debug/Release configurations for codeblocks ?
On Sun, Jul 25, 2010 at 6:58 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: Hmm, the Codeblocks generator is makefile-based. What exactly does makefile-based mean/imply? Each makefile-based buildtree builds only one configuration. If you want multiple configurations, create one buildtree for each configuration (each with its own C::B project file). That doesn't seem right. Olaf ___ 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] Debug/Release configurations for codeblocks ?
On 26. Jul, 2010, at 18:49 , Olaf van der Spek wrote: On Sun, Jul 25, 2010 at 6:58 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: Hmm, the Codeblocks generator is makefile-based. It is single-configuration. What exactly does makefile-based mean/imply? Each makefile-based buildtree builds only one configuration. If you want multiple configurations, create one buildtree for each configuration (each with its own C::B project file). That doesn't seem right. Patches are welcome ;-) I don't think it would be too hard to implement, mostly some Makefile magic, deferring a lot from CMake-time to build-time. However I'm unsure as to how people will like it. An there remains the question of how to select the build type from the command line. I'd hate having to pass make a variable definition... Olaf 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] [VS gen] Multiple configurations code
Hi, Where in the source code does the VS generator generate the multiple configurations? Olaf ___ 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] Debug/Release configurations for codeblocks ?
On Mon, Jul 26, 2010 at 6:59 PM, Michael Wild them...@gmail.com wrote: On 26. Jul, 2010, at 18:49 , Olaf van der Spek wrote: On Sun, Jul 25, 2010 at 6:58 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: Hmm, the Codeblocks generator is makefile-based. It is single-configuration. First let me say I don't know Code Blocks. The question implies Code Blocks project files support multiple configurations. So what does is single-configuration.? Olaf Patches are welcome ;-) I don't think it would be too hard to implement, mostly some Makefile magic, deferring a lot from CMake-time to build-time. However I'm unsure as to how people will like it. Why? An there remains the question of how to select the build type from the command line. I'd hate having to pass make a variable definition... Have a default type in CMakeLists? Olaf ___ 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] [VS gen] Multiple configurations code
On Mon, Jul 26, 2010 at 1:00 PM, Olaf van der Spek olafvds...@gmail.com wrote: Hi, Where in the source code does the VS generator generate the multiple configurations? I believe all of that is in the modules. Its actually pretty easy to edit. I have modified this on my side several times to get CMake to stop creating so many configurations that I would never use. CMake 2.8\share\cmake-2.8\Modules\Platform John ___ 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] Debug/Release configurations for codeblocks ?
First let me say I don't know Code Blocks. The question implies Code Blocks project files support multiple configurations. Yes, is my CMakeList.txt file going to impact the MSVC project file generation, while I am forcing Debug/Release configurations to be built ? ___ 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] [VS gen] Multiple configurations code
grep for CMAKE_CONFIGURATION_TYPES On Mon, Jul 26, 2010 at 1:06 PM, John Drescher dresche...@gmail.com wrote: On Mon, Jul 26, 2010 at 1:00 PM, Olaf van der Spek olafvds...@gmail.com wrote: Hi, Where in the source code does the VS generator generate the multiple configurations? I believe all of that is in the modules. Its actually pretty easy to edit. I have modified this on my side several times to get CMake to stop creating so many configurations that I would never use. CMake 2.8\share\cmake-2.8\Modules\Platform John ___ 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] Info / advise on getting CMake running on Open VMS?
It seems that a few people have attempted to get CMake going on VMS over the years, and there are some VMS specific files in the source tar file, but OpenVMS isn't on the supported list, and is called out on the ToDo Wiki as unsupported. Is there anything I should know, any tips anyone can give, before I attempt this??? Thanks, Kelly Hickel ___ 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] Debug/Release configurations for codeblocks ?
On 26. Jul, 2010, at 19:07 , Carlos wrote: First let me say I don't know Code Blocks. The question implies Code Blocks project files support multiple configurations. Yes, is my CMakeList.txt file going to impact the MSVC project file generation, while I am forcing Debug/Release configurations to be built ? OK, it's like this: CMake has various backends which generate the native build tool. For MSVC, GNU Make, nmake, Xcode etc. Now, some of these backends are multi-config, such as the ones for MSVC and Xcode. That means, the same project file can generate multiple configurations (e.g. Debug, Release or RelWithDebugInfo). Others, the Makefile based ones (GNU Make and nmake) are single-config, where the build system generated by CMake can only build a single configuration which the user selected when configuring the build tree. Since the CodeBlocks generator is actually the GNU Makefiles generator with the addition of the CodeBlocks project file, it inherits these characteristics and can only build a single configuration. Hope this clears things a bit. 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] Debug/Release configurations for codeblocks ?
On Mon, Jul 26, 2010 at 7:23 PM, Michael Wild them...@gmail.com wrote: OK, it's like this: CMake has various backends which generate the native build tool. For MSVC, GNU Make, nmake, Xcode etc. Now, some of these backends are multi-config, such as the ones for MSVC and Xcode. That means, the same project file can generate multiple configurations (e.g. Debug, Release or RelWithDebugInfo). Others, the Makefile based ones (GNU Make and nmake) are single-config, where the build system generated by CMake can only build a single configuration which the user selected when configuring the build tree. Since the CodeBlocks generator is actually the GNU Makefiles generator with the addition of the CodeBlocks project file, it inherits these characteristics and can only build a single configuration. Hope this clears things a bit. Thanks a lot. So the Code Blocks gen isn't native? Just uses a makefile for the build system. That explains it. Olaf ___ 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] Subdirectories and FIND_LIBRARY routines
On 26. Jul, 2010, at 19:09 , Clifford Yapp wrote: Michael, Thanks for an interesting reply. How do you decide what value to put in XXX_LIBRARIES? Is that pulled from the child CMakeLists.txt file back into the parent? CY On Mon, Jul 26, 2010 at 12:46 PM, Michael Wild them...@gmail.com wrote: Where build_thirdparty() is a macro that builds the named package (in my case through ExternalProject_Add) and sets compatibility variables (i.e. the XXX_INCLUDE_DIR and XXX_LIBRARIES variables). This is possible since you can always override the cached values of a variable (the reverse is undefined, however. so be careful). Above code is intentionally a macro, since otherwise it would be cumbersome to propagate the variables XXX_INCLUDE_DIR and XXX_LIBRARIES (and similar ones) to the caller scope. HTH Michael The build_thirdparty macro calls itself other macros, e.g. build_zlib. That one guesses the output location of the zlib libraries, creates an IMPORTED library target and sets XXX_LIBRARIES accordingly. The problem of finding the output location of external projects has been discussed quite a few times, and there is only one really clean, although complex and confusing solution: There is one master project which only makes calls to ExternalProject_Add, even the main project is build as such an external project. 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] Subdirectories and FIND_LIBRARY routines
On Mon, Jul 26, 2010 at 7:28 PM, Michael Wild them...@gmail.com wrote: The build_thirdparty macro calls itself other macros, e.g. build_zlib. That one guesses the output location of the zlib libraries, creates an IMPORTED library target and sets XXX_LIBRARIES accordingly. The problem of finding the output location of external projects has been discussed quite a few times, and there is only one really clean, although complex and confusing solution: There is one master project which only makes calls to ExternalProject_Add, even the main project is build as such an external project. Isn't the solution to use system libs for zlib? Building zlib 'privately' seems like a bad work around. Olaf ___ 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] Subdirectories and FIND_LIBRARY routines
Olaf, zlib is just an example. I'm working on building BRL-CAD, which has a number of such libs, some of them not common at all. Also, the project policy is to have the libs in src/other available for local compile at need, so that part of it isn't up to me :-/. CY On Mon, Jul 26, 2010 at 1:31 PM, Olaf van der Spek olafvds...@gmail.com wrote: On Mon, Jul 26, 2010 at 7:28 PM, Michael Wild them...@gmail.com wrote: The build_thirdparty macro calls itself other macros, e.g. build_zlib. That one guesses the output location of the zlib libraries, creates an IMPORTED library target and sets XXX_LIBRARIES accordingly. The problem of finding the output location of external projects has been discussed quite a few times, and there is only one really clean, although complex and confusing solution: There is one master project which only makes calls to ExternalProject_Add, even the main project is build as such an external project. Isn't the solution to use system libs for zlib? Building zlib 'privately' seems like a bad work around. Olaf ___ 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] Debug/Release configurations for codeblocks ?
On Jul 26, 2010, at 1:02 PM, Olaf van der Spek wrote: On Mon, Jul 26, 2010 at 6:59 PM, Michael Wild them...@gmail.com wrote: On 26. Jul, 2010, at 18:49 , Olaf van der Spek wrote: On Sun, Jul 25, 2010 at 6:58 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: Hmm, the Codeblocks generator is makefile-based. It is single-configuration. First let me say I don't know Code Blocks. The question implies Code Blocks project files support multiple configurations. So what does is single-configuration.? Olaf Patches are welcome ;-) I don't think it would be too hard to implement, mostly some Makefile magic, deferring a lot from CMake- time to build-time. However I'm unsure as to how people will like it. Why? Because it may horrendously interfere with my current established workflows but I would be open to trying this out. The main issue I can think of is the whole release/debug versions of libraries clobbering each other during the build. This would force an updated policy for the decorating of library/executable names or generating sub folders for each type of build configuration. Didn't we just discuss this in another thread? An there remains the question of how to select the build type from the command line. I'd hate having to pass make a variable definition... Have a default type in CMakeLists? Olaf The default is for CMake to generate a Release configuration for Makefile based projects. ie, if you do NOT specify or otherwise set CMAKE_BUILD_TYPE then you will be a Release configuration. Mike Jackson ___ 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] Subdirectories and FIND_LIBRARY routines
Am Monday 26 July 2010 schrieb Michael Wild: The build_thirdparty macro calls itself other macros, e.g. build_zlib. That one guesses the output location of the zlib libraries, creates an IMPORTED library target and sets XXX_LIBRARIES accordingly. The problem of finding the output location of external projects has been discussed quite a few times, and there is only one really clean, although complex and confusing solution: There is one master project which only makes calls to ExternalProject_Add, even the main project is build as such an external project. Which sucks at other places: we some such master projects that pull in a ton of other projects. But sometimes we just want to build one of these subprojects and not a monster which 500+ projects (takes about an hour to build on a recent DualCore with MSVC2008). So we have a macro ADD_SUBDIRECTORY_ONCE that works like ADD_SUBDIRECTORY but checks the cache if that directory has already been included. Now every subproject can A_S_ONCE all of it's dependencies so you can start at many places in the tree and get a correct build. Next problem is when the place where A_S_ONCE was called first (and which pushed it's absolute path into the cache) get's removed from the tree as noone then is including that needed dependency anymore. Nightmare again. Luckyly that doesn't happen too often... Eike signature.asc Description: This is a digitally signed message part. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Debug/Release configurations for codeblocks ?
On Mon, Jul 26, 2010 at 7:12 PM, Michael Jackson mike.jack...@bluequartz.net wrote: Because it may horrendously interfere with my current established workflows Why? but I would be open to trying this out. The main issue I can think of is the whole release/debug versions of libraries clobbering each other during the build. This would force an updated policy for the decorating of library/executable names or generating sub folders for each type of build configuration. Doesn't Code Blocks have a convention like this already? Didn't we just discuss this in another thread? Yes, we did. The default is for CMake to generate a Release configuration for Makefile based projects. ie, if you do NOT specify or otherwise set CMAKE_BUILD_TYPE then you will be a Release configuration. AFAIK that's false. Olaf ___ 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] Debug/Release configurations for codeblocks ?
2010/7/26 Olaf van der Spek olafvds...@gmail.com: On Mon, Jul 26, 2010 at 7:23 PM, Michael Wild them...@gmail.com wrote: OK, it's like this: CMake has various backends which generate the native build tool. For MSVC, GNU Make, nmake, Xcode etc. Now, some of these backends are multi-config, such as the ones for MSVC and Xcode. That means, the same project file can generate multiple configurations (e.g. Debug, Release or RelWithDebugInfo). Others, the Makefile based ones (GNU Make and nmake) are single-config, where the build system generated by CMake can only build a single configuration which the user selected when configuring the build tree. Since the CodeBlocks generator is actually the GNU Makefiles generator with the addition of the CodeBlocks project file, it inherits these characteristics and can only build a single configuration. Hope this clears things a bit. Thanks a lot. So the Code Blocks gen isn't native? Just uses a makefile for the build system. That explains it. It depends on what you mean by native. The project file for Code::Blocks is generated by CMake but Code::Blocks may be used with external makefile(s) which are generated by CMake too. You have the same scheme with the Eclipse CDT4 generator. Those generatord are Extra generator which relies on the Makefile generator. You may have a look at the source for: CMake/Source/cm[Local|Global|Extra]XXXGenerator.[h|cxx] XXX being [part of] the generator name the user is used to know. Extra means the generator depends on another generator I don't know the design idea behind Local and Global. -- 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] Debug/Release configurations for codeblocks ?
On Mon, Jul 26, 2010 at 8:32 PM, Eric Noulard eric.noul...@gmail.com wrote: Thanks a lot. So the Code Blocks gen isn't native? Just uses a makefile for the build system. That explains it. It depends on what you mean by native. The project file for Code::Blocks is generated by CMake but Code::Blocks may be used with external makefile(s) which are generated by CMake too. By native I mean what Code Blocks projects use by default. I assume they don't use an external makefile. Olaf ___ 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] Debug/Release configurations for codeblocks ?
On Jul 26, 2010, at 2:23 PM, Olaf van der Spek wrote: On Mon, Jul 26, 2010 at 7:12 PM, Michael Jackson mike.jack...@bluequartz.net wrote: Because it may horrendously interfere with my current established workflows Why? but I would be open to trying this out. The main issue I can think of is the whole release/debug versions of libraries clobbering each other during the build. This would force an updated policy for the decorating of library/executable names or generating sub folders for each type of build configuration. Doesn't Code Blocks have a convention like this already? Didn't we just discuss this in another thread? Yes, we did. The default is for CMake to generate a Release configuration for Makefile based projects. ie, if you do NOT specify or otherwise set CMAKE_BUILD_TYPE then you will be a Release configuration. AFAIK that's false. Olaf Hmm. At some point it was because I specifically asked on this list a number of years ago. Maybe things have changed. ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio ___ 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] Debug/Release configurations for codeblocks ?
2010/7/26 Olaf van der Spek olafvds...@gmail.com: On Mon, Jul 26, 2010 at 8:32 PM, Eric Noulard eric.noul...@gmail.com wrote: Thanks a lot. So the Code Blocks gen isn't native? Just uses a makefile for the build system. That explains it. It depends on what you mean by native. The project file for Code::Blocks is generated by CMake but Code::Blocks may be used with external makefile(s) which are generated by CMake too. By native I mean what Code Blocks projects use by default. I assume they don't use an external makefile. No you are right the default is to use some builtin project file and dependency tracking etc... Now if you look at the Eclipse CDT4 generator this difference blurs because Eclipse CDT do use Makefiles bu they can be managed (generated by Eclipse CDT) or custom/unmanaged and that's the way it is used with CMake Eclipse CDT generator. -- 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] [VS gen] Multiple configurations code
On Mon, Jul 26, 2010 at 7:07 PM, David Cole david.c...@kitware.com wrote: grep for CMAKE_CONFIGURATION_TYPES I'm quite sure adding more configuration types here won't suffice. IF(NOT CMAKE_NO_BUILD_TYPE AND CMAKE_GENERATOR MATCHES Visual Studio) SET (CMAKE_NO_BUILD_TYPE 1) SET (CMAKE_CONFIGURATION_TYPES Debug;Release;MinSizeRel;RelWithDebInfo CACHE STRING Semicolon separated list of supported configuration types, only supports Debug, Release, MinSizeRel, and RelWithDebInfo, anything else will be ignored.) MARK_AS_ADVANCED(CMAKE_CONFIGURATION_TYPES) ENDIF(NOT CMAKE_NO_BUILD_TYPE AND CMAKE_GENERATOR MATCHES Visual Studio) Olaf ___ 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] [VS gen] Multiple configurations code
On Mon, Jul 26, 2010 at 2:57 PM, Olaf van der Spek olafvds...@gmail.com wrote: On Mon, Jul 26, 2010 at 7:07 PM, David Cole david.c...@kitware.com wrote: grep for CMAKE_CONFIGURATION_TYPES I'm quite sure adding more configuration types here won't suffice. IF(NOT CMAKE_NO_BUILD_TYPE AND CMAKE_GENERATOR MATCHES Visual Studio) SET (CMAKE_NO_BUILD_TYPE 1) SET (CMAKE_CONFIGURATION_TYPES Debug;Release;MinSizeRel;RelWithDebInfo CACHE STRING Semicolon separated list of supported configuration types, only supports Debug, Release, MinSizeRel, and RelWithDebInfo, anything else will be ignored.) MARK_AS_ADVANCED(CMAKE_CONFIGURATION_TYPES) ENDIF(NOT CMAKE_NO_BUILD_TYPE AND CMAKE_GENERATOR MATCHES Visual Studio) You need to add variables and such. I believe that is done in windows-cl.cmake John ___ 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] [VS gen] Multiple configurations code
On Mon, Jul 26, 2010 at 9:00 PM, John Drescher dresche...@gmail.com wrote: You need to add variables and such. I believe that is done in windows-cl.cmake I'd like to generate both dynamic and static, x86 and x64 configs. CMake already knows how to build those, so it's not about adding variables for those. Olaf ___ 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] [VS gen] Multiple configurations code
On Mon, Jul 26, 2010 at 3:03 PM, Olaf van der Spek olafvds...@gmail.com wrote: On Mon, Jul 26, 2010 at 9:00 PM, John Drescher dresche...@gmail.com wrote: You need to add variables and such. I believe that is done in windows-cl.cmake I'd like to generate both dynamic and static, x86 and x64 configs. CMake already knows how to build those, so it's not about adding variables for those. I believe you still need to fill in the details for the new configurations. Here is part of Windows-cl.cmake SET (CMAKE_CXX_FLAGS_INIT /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR) SET (CMAKE_CXX_FLAGS_DEBUG_INIT /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1) SET (CMAKE_CXX_FLAGS_MINSIZEREL_INIT /MD /O1 /Ob1 /D NDEBUG) SET (CMAKE_CXX_FLAGS_RELEASE_INIT /MD /O2 /Ob2 /D NDEBUG) SET (CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT /MD /Zi /O2 /Ob1 /D NDEBUG) As for 64bit / 32 bit I do not think this is a simple modification to allow 64bit and be 100% correct. John ___ 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] [VS gen] Multiple configurations code
On Mon, Jul 26, 2010 at 3:12 PM, John Drescher dresche...@gmail.com wrote: On Mon, Jul 26, 2010 at 3:03 PM, Olaf van der Spek olafvds...@gmail.com wrote: On Mon, Jul 26, 2010 at 9:00 PM, John Drescher dresche...@gmail.com wrote: You need to add variables and such. I believe that is done in windows-cl.cmake I'd like to generate both dynamic and static, x86 and x64 configs. CMake already knows how to build those, so it's not about adding variables for those. I believe you still need to fill in the details for the new configurations. Here is part of Windows-cl.cmake SET (CMAKE_CXX_FLAGS_INIT /DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR) SET (CMAKE_CXX_FLAGS_DEBUG_INIT /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1) SET (CMAKE_CXX_FLAGS_MINSIZEREL_INIT /MD /O1 /Ob1 /D NDEBUG) SET (CMAKE_CXX_FLAGS_RELEASE_INIT /MD /O2 /Ob2 /D NDEBUG) SET (CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT /MD /Zi /O2 /Ob1 /D NDEBUG) As for 64bit / 32 bit I do not think this is a simple modification to allow 64bit and be 100% correct. Olaf, It's definitely not easy to make such a modification with the current VS generators. For better or for worse, there are currently separate generators for Visual Studio 32-bit and 64-bit projects. It would be a major re-working of those separate generators to combine them into a single one that chose the architecture at *build* time rather than at configure time. Many projects already have logic in their CMakeLists.txt files that goes something like this: if(CMAKE_SIZEOF_VOID_P EQUAL 8) # do 64-bit stuff at *configure* time... else() # 32-bit stuff endif() If you make *configure* time decisions based on architecture, then it's not easy to support multiple architectures without multiple configures. (Multiple build trees...) Since this is a prevalent scheme that is widely used by folks coming from single-config, single-architecture (makefile based) build systems... it's the way CMake has gotten to the point it's at now. I'm not saying this is good or bad, just explaining that this is the way it is, and that there are historical reasons why we got to this point. So what you're attempting is probably possible, but it's definitely not easy. And it will probably require some significant re-work of the existing code. Let us know if you have any other specific questions that we can answer for you. Hope this helps, David Cole Kitware, Inc. ___ 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] Debug/Release configurations for codeblocks ?
On Monday 26 July 2010, Olaf van der Spek wrote: On Mon, Jul 26, 2010 at 7:12 PM, Michael Jackson mike.jack...@bluequartz.net wrote: Because it may horrendously interfere with my current established workflows Why? but I would be open to trying this out. The main issue I can think of is the whole release/debug versions of libraries clobbering each other during the build. This would force an updated policy for the decorating of library/executable names or generating sub folders for each type of build configuration. Doesn't Code Blocks have a convention like this already? Maybe/probably CodeBlocks supports this when using native project files, i.e. not project files for already existing makefiles (this is what cmake generates). The way it is now (project files + makefiles) is an order of magnitude less implementation and maintainance work than a native C::B generator. But if somebody steps up, implements one and maintains it (i.e. makes sure all tests always succeed), I don't see a reason why such a generator would not be accepted and replace the current one. 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] How to exclude empty dirs from install
On Friday 23 July 2010, Brian Davis wrote: --snip-- Because if they were excluded, we would have someone on the list next month asking why she can't create empty directories with install() commands. --end snip-- True point taken. Then we would have 2 people who are correct ... Olaf and this said hypothetic other person. With software there is: 1) The way it should work 2) The way it was designed to work 2) The way it was documented to work 3) The way it does work Rarely do these four things agree in software. And rarely they way it should work means the same if the number of opinions considered is = 2 ;-) When they do it is only for a brief time when it is replaced with a version that is better in my experience. These discussions are the only way to make CMake actually better (or suck less - which is all I think any of us can hope for)... Keep up the good work Olaf! 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] Avoid losing changes in Xcode when changing CMakeLists.txt
On Thursday 22 July 2010, Michael Wild wrote: On 22. Jul, 2010, at 15:57 , David Ojeda wrote: Hello CMakers! I am coding with some teammates that use Xcode as their IDE. Everything is working fine thanks to CMake, except for the following situation: 1. Developer X checkouts a project from svn and uses CMake to generate their Xcode project 2. Developer X succesfully compiles their executables and configures this executables in the Xcode environment (for example, he changes its arguments, library configurations for debugging, etc). 3. Developer Y checkouts the same project from svn and changes CMakeLists.txt (for example, he adds another library dependency or a new source file). 4. Developer Y commits its changes 5. Developer X updates its project and must re-generate their Xcode project. 6. PROBLEM: All changes made at step 2 were lost for Developer X. Have any of you had this problem before? How can I maintain developer X's settings? Thanks for your ideas! David. Well, tell X not to change anything in Xcode ;-) Either make the changes in the cache, or if otherwise not possible, modify the CMake code, which would mean either: when generating the new Xcode project file, merge the settings with the already existing one (of there are settings which can be changed by the user and which are not set at all by cmake), or, add some special cache variables to cmake which can be changed by the user and will be used by the Xcode generator to write these specific entries in the project 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] Subdirectories and FIND_LIBRARY routines
On 26. Jul, 2010, at 19:51 , Rolf Eike Beer wrote: Am Monday 26 July 2010 schrieb Michael Wild: The build_thirdparty macro calls itself other macros, e.g. build_zlib. That one guesses the output location of the zlib libraries, creates an IMPORTED library target and sets XXX_LIBRARIES accordingly. The problem of finding the output location of external projects has been discussed quite a few times, and there is only one really clean, although complex and confusing solution: There is one master project which only makes calls to ExternalProject_Add, even the main project is build as such an external project. Which sucks at other places: we some such master projects that pull in a ton of other projects. But sometimes we just want to build one of these subprojects and not a monster which 500+ projects (takes about an hour to build on a recent DualCore with MSVC2008). So we have a macro ADD_SUBDIRECTORY_ONCE that works like ADD_SUBDIRECTORY but checks the cache if that directory has already been included. Now every subproject can A_S_ONCE all of it's dependencies so you can start at many places in the tree and get a correct build. Next problem is when the place where A_S_ONCE was called first (and which pushed it's absolute path into the cache) get's removed from the tree as noone then is including that needed dependency anymore. Nightmare again. Luckyly that doesn't happen too often... Eike You shouldn't store such information in the cache, that's definitely the wrong place. Use a global property instead, which only lives during the CMake run. This way, when you remove a sub-project, another one will step in to fill the gap. HTH 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] [VS gen] Multiple configurations code
On Mon, Jul 26, 2010 at 9:21 PM, David Cole david.c...@kitware.com wrote: Olaf, It's definitely not easy to make such a modification with the current VS generators. For better or for worse, there are currently separate generators for Visual Studio 32-bit and 64-bit projects. It would be a major re-working of those separate generators to combine them into a single one that chose the architecture at *build* time rather than at configure time. Why are there two generators? I don't see why the decision has to be made at another time. Configure time is fine with me. Many projects already have logic in their CMakeLists.txt files that goes something like this: if(CMAKE_SIZEOF_VOID_P EQUAL 8) # do 64-bit stuff at *configure* time... else() # 32-bit stuff endif() If you make *configure* time decisions based on architecture, then it's not easy to support multiple architectures without multiple configures. (Multiple build trees...) Is there a problem with multiple configures / build trees? Since this is a prevalent scheme that is widely used by folks coming from single-config, single-architecture (makefile based) build systems... it's the way CMake has gotten to the point it's at now. I'm not saying this is good or bad, just explaining that this is the way it is, and that there are historical reasons why we got to this point. So what you're attempting is probably possible, but it's definitely not easy. And it will probably require some significant re-work of the existing code. Let us know if you have any other specific questions that we can answer for you. x64 is not a priority for me ATM. Having static configs (static lib, static runtime and static lib, dynamic runtime) is more important. Olaf ___ 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 generators on windows: nmake versus jom
On Monday 26 July 2010, Verweij, Arjen wrote: Hi Alex, Will this do? http://www.cmake.org/Wiki/CMake_Generator_Specific_Information#Makefile_gen erators Sure, thanks :-) 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] Configuring targets software that isn't yet built
On Wednesday 21 July 2010, Brian Davis wrote: I too would like the answer to this and other questions. I have been having the same problem with CMake (among others) How to build a project that contains multiple 3rd party sources where: 1) build of one package is dependent on the not yet installed install of a dependency package where the install of the dependency is part of the uber project. This occurs where all source of multiple 3rd party packages is contained in the source tree where it is checked out cleanly build on a build server or user machine and there is one CMakeLists.txt file which defines the project without having to call CMake multiple times for each project. 2) modularity in the use of add_subdirectory or as of yet a not net defined alternative in CMake where 3rd Party packages would not blast away each others global CMAKE_C_FLAGS due to the inevitalbe use by each 3rdParty project of CACHE STRING FORCE etc. My desire for namespaces when add_subdirecoty is called or project(someproject) is called. EXTERNAL_PROJECT_ADD (though I am forced to do this for vtk, dcmtk, and VTKEdge) is not the solution (IMHO) for these issues as I am forced to build the entire project for only a few needed dependencies. If you choose this route then use EXTERNAL_PROJECT_ADD for each project then use add_dependency linking the projects in order of their dependencies. This worked for me, but mileage may vary. I'm doing something similar, but I hit a problem when adding the dependencies so that the external projects are actually built. The issues is that it is currently not possible to use add_dependencies() with imported targets, here's the issue for it: http://public.kitware.com/Bug/view.php?id=10395 Would that help in your case too ? 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] Parallel build with ctest 2.8.2
On Wednesday 21 July 2010, Ryan Pavlik wrote: My CreateDashboardScripts.cmake and DashboardScript.cmake.in located in this repository might be a useful example - I also had a hard time figuring out how to do the new-style script. http://github.com/rpavlik/wiimote-head-tracker-gui/tree/master/cmake/ For use by KDE4 I wrote KDECTestNightly.cmake, which you can find here: http://websvn.kde.org/trunk/KDE/kdesdk/cmake/nightly-support/ , complete with documentation at the top. It does not yet support git. It is actually completely KDE independent and can be used also for non-KDE non-Qt projects. The kde_ prefix is just used to point out that these varibales/macros do not come from the ctest as it comes with cmake, but from the extra module. It's a cmake module which offers some functions/macros and variables for use in new-style ctest scripts, to make it easier to write them. Here is an example ctest-script which drives the nightly build of the kdelibs project: http://websvn.kde.org/trunk/KDE/kdesdk/cmake/nightly-support/KDE/KDELibsNightly.cmake?revision=1117002view=markup 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] Adding .lib dependencies
On Thursday 15 July 2010, Chris Robison wrote: I'm trying to create a project that embeds mono. I'm using Visual Studio 2010. In VS, I would normally go to Project - Properties - Linker - Input and adjust the Additional Dependencies list. How do you add items to this list in CMake? I've been playing around with add_library and target_link_libraries but I haven't had much success. If I understand correctly, this should be target_link_libraries(). You use it either with libraries built in the same project using add_library(foo ), then you use just the target name (foo) in target_link_libraries(), or with already existing libraries, which you should search before using find_library(FOO_LIBRARY ...), which gives you the full path to the library in FOO_LIBRRARY, which you then use in target_link_libraries(). 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] [VS gen] Multiple configurations code
On Jul 26, 2010, at 3:46 PM, Olaf van der Spek wrote: On Mon, Jul 26, 2010 at 9:21 PM, David Cole david.c...@kitware.com wrote: Olaf, It's definitely not easy to make such a modification with the current VS generators. For better or for worse, there are currently separate generators for Visual Studio 32-bit and 64-bit projects. It would be a major re-working of those separate generators to combine them into a single one that chose the architecture at *build* time rather than at configure time. Why are there two generators? I don't see why the decision has to be made at another time. Configure time is fine with me. Many projects already have logic in their CMakeLists.txt files that goes something like this: if(CMAKE_SIZEOF_VOID_P EQUAL 8) # do 64-bit stuff at *configure* time... else() # 32-bit stuff endif() If you make *configure* time decisions based on architecture, then it's not easy to support multiple architectures without multiple configures. (Multiple build trees...) Is there a problem with multiple configures / build trees? No, which is what is done now, just at a higher level than you are wanting. You would like to have Win32 and Win64 in the same solution file which would require multiple configure runs in the same build directory. Currently CMake requires the developer to create 2 distinct build trees, one for Win32 and one for Win64 where each build directory is configured with the appropriate compiler version. So same idea just implemented slightly differently. Since this is a prevalent scheme that is widely used by folks coming from single-config, single-architecture (makefile based) build systems... it's the way CMake has gotten to the point it's at now. I'm not saying this is good or bad, just explaining that this is the way it is, and that there are historical reasons why we got to this point. So what you're attempting is probably possible, but it's definitely not easy. And it will probably require some significant re-work of the existing code. Let us know if you have any other specific questions that we can answer for you. x64 is not a priority for me ATM. Having static configs (static lib, static runtime and static lib, dynamic runtime) is more important. Olaf It may not be a priority for _you_ but it is a requirement for me. The code snippet that David C. put in there is extremely important to get right and the ONLY way to get it right is to run configure multiple times for each Arch. Just have a look at any project that attempts to support Universal Binaries on OS X. The same problem exists. One has to make sure that the sizes of pointers and some primitives are correct so header file generation is correct. ___ 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] Quieting/speeding output
On Sunday 11 July 2010, Kevin Fitch wrote: I am transitioning from a make based build system to cmake, overall I am quite happy with cmake, but currently there are two snags: 1) The main project I am doing this on is quite large, it produces about 300 targets. So, when I type 'make' I get 300 or so lines of [ 27%] Built target blah... even when there is nothing (or very little) to do. This is quite annoying. I tried messing with CMAKE_RULE_MESSAGES. I just added -DCMAKE_RULE_MESSAGES=OFF to the cmake invocation. But that didn't seem to help. 2) The follow on to this is that a 'do-nothing' build still takes about 4 seconds (or about 1.25 seconds for make -j. The previous make based build was effectively instantaneous for a 'do-nothing' build. The do-nothing (or do very little) build is the common case so I hate to regress that far. Where should I be looking to address these issues? If you want to build just one target, e.g. foo, there are targets foo/fast which skip the dependency skipping of dependent targets, i.e. it doesn't check the dependencies of libraries against which foo links. So, most of the time is spent in dependency checking. 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] [VS gen] Multiple configurations code
On Mon, Jul 26, 2010 at 10:05 PM, Michael Jackson mike.jack...@bluequartz.net wrote: Is there a problem with multiple configures / build trees? No, which is what is done now, just at a higher level than you are wanting. You would like to have Win32 and Win64 in the same solution file which would require multiple configure runs in the same build directory. Currently CMake requires the developer to create 2 distinct build trees, one for Win32 and one for Win64 where each build directory is configured with the appropriate compiler version. So same idea just implemented slightly differently. I understand. The developer shouldn't have to do this. It may not be a priority for _you_ but it is a requirement for me. The code snippet that David C. put in there is extremely important to get right and the ONLY way to get it right is to run configure multiple times for each Arch. Just have a look at any project that attempts to support Universal Binaries on OS X. The same problem exists. One has to make sure that the sizes of pointers and some primitives are correct so header file generation is correct. I'm not saying it shouldn't be solved. ;) Olaf ___ 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] [VS gen] Multiple configurations code
On Mon, Jul 26, 2010 at 3:46 PM, Olaf van der Spek olafvds...@gmail.comwrote: On Mon, Jul 26, 2010 at 9:21 PM, David Cole david.c...@kitware.com wrote: Olaf, It's definitely not easy to make such a modification with the current VS generators. For better or for worse, there are currently separate generators for Visual Studio 32-bit and 64-bit projects. It would be a major re-working of those separate generators to combine them into a single one that chose the architecture at *build* time rather than at configure time. Why are there two generators? I don't see why the decision has to be made at another time. Configure time is fine with me. Maybe I'm misinterpreting what you're asking. I thought you said you wanted x86 and x64 both in the same build tree. That would be not making a choice at configure time, and deferring the choice of arch to build time. But with CMake as is, it is typically a configure time choice in most projects. As to why there are two generators, I don't understand the precise decisions behind having it done it that way. Perhaps if somebody else knows, they will chime in. (I've lamented this fact before when folks have asked about adding config types for various phone- OSes...) Many projects already have logic in their CMakeLists.txt files that goes something like this: if(CMAKE_SIZEOF_VOID_P EQUAL 8) # do 64-bit stuff at *configure* time... else() # 32-bit stuff endif() If you make *configure* time decisions based on architecture, then it's not easy to support multiple architectures without multiple configures. (Multiple build trees...) Is there a problem with multiple configures / build trees? No, not at all. We do this all the time. But again, I thought from your questions that you were trying to do it all in one build tree. Since this is a prevalent scheme that is widely used by folks coming from single-config, single-architecture (makefile based) build systems... it's the way CMake has gotten to the point it's at now. I'm not saying this is good or bad, just explaining that this is the way it is, and that there are historical reasons why we got to this point. So what you're attempting is probably possible, but it's definitely not easy. And it will probably require some significant re-work of the existing code. Let us know if you have any other specific questions that we can answer for you. x64 is not a priority for me ATM. Having static configs (static lib, static runtime and static lib, dynamic runtime) is more important. Olaf ___ 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] contribution: FindMySQL.cmake
On Tuesday 06 July 2010, Arnaud GELAS wrote: Hi guys, We have been for our own projects the following file to find mysql packages, and I would like to contribute it to the community. Note: it works fine for MySQL 5.1 on Windows (tested on XP and 7), Mac (tested on 10.5 and 10.6) and Linux. I guess it could be improved for other version of MySQL (older one, or beta ones), I would be happy to help in the improvement of this file. Here's the short documentation how to get a new module into cmake: http://www.cmake.org/Wiki/CMake:Module_Maintainers 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] [VS gen] Multiple configurations code
On Mon, Jul 26, 2010 at 10:12 PM, David Cole david.c...@kitware.com wrote: Is there a problem with multiple configures / build trees? No, not at all. We do this all the time. But again, I thought from your questions that you were trying to do it all in one build tree. I'm not familiar with the term build tree. Let's describe what I'd like: I've got a single CMakeLists.txt for a lib named xbt. I've got xbt.h and xbt.cpp. I'm using VS (2010). With a few simple commands, I should be able to build and package all possible configurations of this lib. In the ideal case, this would be cmake ., nmake ... or similar. It should not be necessary to modify CMakeLists or to have multiple copies of the source. Olaf ___ 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] option bug ?
On Monday 12 July 2010, Michael Hertling wrote:
On 07/07/2010 09:44 AM, Michael Wild wrote:
On 7. Jul, 2010, at 9:32 , Michael Hertling wrote:
On 07/03/2010 01:03 AM, Chris Hillery wrote:
There's a slightly nicer work-around: Change project A's CMakeLists to
set PROJB_OPENCV_LINK as a cache variable, ie, SET(PROJB_OPENCV_LINK NO
CACHE BOOLEAN doc). I've tested it locally and it works the way you
want it to.
It seems that CMake divides the world of variables into two classes:
cache variables and non-cache variables. Somewhat unfortunately, the
same function, SET(), is used to specify values for both kinds, and
cache variables hide any non-cache variables with the same name. The
upshot is that the same SET() command will do different things
depending on what's currently in the cache.
Further confusion here comes from the fact that when a variable is
declared as a cache variable (using either option() or set(...CACHE...)
), any current value that the non-cache variable with the same name has
is discarded. So the first time you run cmake, PROJB_OPENCV_LINK isn't
a cache variable until it gets to processing projb's CMakeLists.txt,
hence the non-cache value you provided gets dropped. The second time,
it's already a cache variable, so project A's CMakeLists actually sets
the cache variable, and therefore projb's CMakeLists sees it as you
expect.
It's definitely confusing, but I'm not totally sure what the right
solution is. It probably would have been cleaner if CMake made the
distinction clear between cache and non-cache variables, but it's far
too late to change that now. Maybe it would be possible to change it
such that a cache variable declaration (option() or set(...CACHE...) )
would allow a current non-cache variable of the same name to override
the declaration's default value, in the same way that -D on the
command-line does.
IMO, things aren't sooo bad. ;-)
W.r.t. the value of a variable, CMake knows scopes and the cache. A new
scope is entered by ADD_SUBDIRECTORY() or a function's invocation. When
referring to a variable's value by the ${} operator you get the value
from the current scope. At the start of a CMake run, the variables are
initialized with the values from the cache, provided the latter exists
and is appropriately populated. The SET() command - that is the actual
source of confusion along with OPTION() - basically has four flavours:
(1) SET(VAR xyz) sets the value of VAR in the current scope to xyz,
i.e. ${VAR} yields xyz until the value of VAR is changed anew.
(2) SET(VAR xyz PARENT_SCOPE) sets the value of VAR in the parent's
scope to xyz, but doesn't affect the current scope or the cache.
(3) SET(VAR xyz CACHE STRING ... FORCE) sets VAR's value in the
current scope and in the cache to xyz regardless if there's
already a cached value or VAR is defined in the current scope.
(4) SET(VAR xyz CACHE STRING ...) sets VAR's value in the cache
to xyz unless there's already a cached value for VAR, and the
latter's value in the current scope is set from the cache if
(a) the SET() writes to the cache, or
(b) VAR is undefined in the current scope, or
(c) the type of VAR in the cache is UNINITIALIZED.
While (4a,b) are quite reasonable, (4c) is somewhat strange as it
yields different results for apparently equivalent invocations:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(VARS NONE)
MESSAGE(VAR{1,2}[CACHE]: ${VAR1},${VAR2})
SET(VAR1 abc)
SET(VAR2 abc)
MESSAGE(VAR{1,2}[LOCAL]: ${VAR1},${VAR2})
UNSET(VAR2)
SET(VAR1 xyz CACHE STRING )
SET(VAR2 xyz CACHE STRING )
MESSAGE(VAR{1,2}[FINAL]: ${VAR1},${VAR2})
Cmaking from a clean build directory yields, as expected, (4a):
VAR{1,2}[CACHE]: ,
VAR{1,2}[LOCAL]: abc,abc
VAR{1,2}[FINAL]: xyz,xyz
Afterwards, cmake -DVAR1:STRING=pqr -DVAR2:STRING=pqr . yields:
VAR{1,2}[CACHE]: pqr,pqr
VAR{1,2}[LOCAL]: abc,abc
VAR{1,2}[FINAL]: abc,pqr
So, VAR1 is finally not set from the cache, but VAR2 is as it's
undefined in the current scope at that moment; this proves (4b).
Now, cmake -DVAR1=pqr -DVAR2=pqr . reveals (4c):
VAR{1,2}[CACHE]: pqr,pqr
VAR{1,2}[LOCAL]: abc,abc
VAR{1,2}[FINAL]: pqr,pqr
The parameter -DVAR1=pqr, i.e. without a type, supplies the cache
with VAR1:UNINITIALIZED=pqr for VAR1, and the subsequent command
SET(VAR1 xyz CACHE STRING ) changes VAR1's type to STRING, but
does not touch the cached value; though, the latter is written to
VAR1 in the current scope. Here, I'm in doubt if this behaviour is
really intended.
To summarize: If none of (4a-c) holds, i.e. an already cached value
for VAR with a type other than UNINITIALIZED and VAR defined in the
current scope, SET(VAR xyz CACHE STRING ...) just does nothing.
It's that (4a-c) which causes the confusion in regard to a variable's
value in the cache and the current
Re: [CMake] [VS gen] Multiple configurations code
On Mon, Jul 26, 2010 at 4:24 PM, Olaf van der Spek olafvds...@gmail.com wrote: On Mon, Jul 26, 2010 at 10:12 PM, David Cole david.c...@kitware.com wrote: Is there a problem with multiple configures / build trees? No, not at all. We do this all the time. But again, I thought from your questions that you were trying to do it all in one build tree. I'm not familiar with the term build tree. Let's describe what I'd like: I've got a single CMakeLists.txt for a lib named xbt. I've got xbt.h and xbt.cpp. I'm using VS (2010). With a few simple commands, I should be able to build and package all possible configurations of this lib. In the ideal case, this would be cmake ., nmake ... or similar. It should not be necessary to modify CMakeLists or to have multiple copies of the source. You do not have multiple copies of the source. You have 1 copy of the source that you build in multiple trees. For me I build 32 and 64 bit for multiple compilers. They all share the same source tree but have different build trees. For example my source is in X:\CmakeBased My builds are in X:\32bit\vs.71 X:\32bit\vs.80 X:\32bit\vs.90 X:\64bit\vs.80 X:\64bit\vs.90 For each build I need to open the appropriate project file in the build tree. John ___ 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] PROJECT() command when cross compiling
On Friday 09 July 2010, Kishore wrote: On Wednesday 07 Jul 2010 8:54:52 pm Kishore wrote: On Friday 02 Jul 2010 12:36:17 am Kishore wrote: On Friday 02 Jul 2010 12:07:07 am Alexander Neundorf wrote: On Thursday 01 July 2010, Kishore wrote: It seems that the PROJECT() command does a fair bit behind the scenes and is not documented enough. It seems to reset several variable created before it was first called. Since i use cmake from cross compilation, i have created Platform files for Generic-gcc.cmake and Generic-gcc-uc3b1256.cmake (for the processor that I use) 1) It seems that these files are invoked inside the PROJECT() command 2) The platform files set up some needed variables such as CMAKE_C_FLAGS 3) When the PROJECT() command finishes, the variable CMAKE_C_FLAGS is again empty. project() automatically enable the languages, if no languages are given, it tries C and C++. While doing this, a whole bunch of variables are set. Fair enough. But then it should take into account the values i have set for some of those variables in the platform modules. OTOH if it's wrong to be setting those variables in the platform files where else should they be set and what is the role of they platfrom modules? This does not seem to be well documented but the way to actually set the right values for those variable is to use the VAR_INIT form. This works as expected but is not a documented variable. Similarly, in my project, I want to configure in Release mode if the user does not explicitly specify any at cmake time. Again, the solution for this seems to be SET(CMAKE_BUILD_TYPE_INIT Release) PROJECT(MyProject) i.e. set the variable CMAKE_BUILD_TYPE_INIT before the first call to PROJECT(). Hope this helps someone. I wonder how many such *_INIT variables are understood by cmake. The price we pay for using undocumented features... And it turns out that CMAKE_C_LINK_FLAGS_INIT is not an understood variable in cmake. So far i know these work CMAKE_C_FLAGS_INIT CMAKE_BUILD_TYPE_INIT CMake devs, are these variables just missing documentation or are they really not meant to be used? They are quite internal... 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] [VS gen] Multiple configurations code
On Mon, Jul 26, 2010 at 10:31 PM, John Drescher dresche...@gmail.com wrote: You do not have multiple copies of the source. You have 1 copy of the source that you build in multiple trees. For me I build 32 and 64 bit for multiple compilers. They all share the same source tree but have different build trees. For example my source is in X:\CmakeBased My builds are in X:\32bit\vs.71 X:\32bit\vs.80 X:\32bit\vs.90 X:\64bit\vs.80 X:\64bit\vs.90 For each build I need to open the appropriate project file in the build tree. Isn't it easier to use the command line? If this is automated, it's not too bad. Does CMake provide a way to automate this? Olaf ___ 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 - platform files
On Friday 02 July 2010, Kishore wrote:
On Thursday 01 Jul 2010 8:13:56 pm Kishore wrote:
In the CMake wiki (http://www.cmake.org/Wiki/CMake_Cross_Compiling) it
says clearly that the platform module are included in the following
order;
Platform/${CMAKE_SYSTEM_NAME}.cmake (mandatory)
Platform/${CMAKE_SYSTEM_NAME}-compiler.cmake (optional)
Platform/${CMAKE_SYSTEM_NAME}-compiler-${CMAKE_SYSTEM_PROCESSOR}.cmake
(optional)
However, in my project it seems that They are included in the reverse
order to that. At least, Generic-gcc-${CMAKE_SYSTEM_PROCESSOR}.cmake is
included before Generic-gcc.cmake.
Can someone kindly confirm. Is this a bug in cmake or an error in
documentation?
Anyone? What was the original intension when cresting this feature?
Wiki page seems to be wrong.
The CMAKE_SYSTEM_PROCESSOR file is included first so that there
hardware-specific flags can be set, which can then be inserted into the
compile or link variables in the more generic
${CMAKE_SYSTEM_NAME}-compiler.cmake file.
This is usually necessary when working on embedded projects where different
compiler or linker flags are needed depending on the target hardware.
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] [VS gen] Multiple configurations code
On Jul 26, 2010, at 4:35 PM, Olaf van der Spek wrote: On Mon, Jul 26, 2010 at 10:31 PM, John Drescher dresche...@gmail.com wrote: You do not have multiple copies of the source. You have 1 copy of the source that you build in multiple trees. For me I build 32 and 64 bit for multiple compilers. They all share the same source tree but have different build trees. For example my source is in X:\CmakeBased My builds are in X:\32bit\vs.71 X:\32bit\vs.80 X:\32bit\vs.90 X:\64bit\vs.80 X:\64bit\vs.90 For each build I need to open the appropriate project file in the build tree. Isn't it easier to use the command line? If this is automated, it's not too bad. Does CMake provide a way to automate this? Olaf One can create a shell or batch file to pretty easily set this up. It is debatable if this type of functionality is needed in cmake itself but by all means put in a feature request. Mike Jackson ___ 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] [VS gen] Multiple configurations code
On 26.07.10 22:24:11, Olaf van der Spek wrote: On Mon, Jul 26, 2010 at 10:12 PM, David Cole david.c...@kitware.com wrote: Is there a problem with multiple configures / build trees? No, not at all. We do this all the time. But again, I thought from your questions that you were trying to do it all in one build tree. I'm not familiar with the term build tree. That seems to be your problem here. The so-called source tree is the project folder on your disk containing the actual source files and the CMakeLists.txt files. The build-tree on the other hand is the folder in which you run cmake to generate the build files (Makefiles or whatever). Let's describe what I'd like: I've got a single CMakeLists.txt for a lib named xbt. I've got xbt.h and xbt.cpp. I'm using VS (2010). With a few simple commands, I should be able to build and package all possible configurations of this lib. In the ideal case, this would be cmake ., nmake ... or similar. The usual way with Makefiles is to: setup tools for x64/release mkdir x64_release cd x64_release cmake .. nmake setup tools for x64/debug mkdir x64_debug cd x64_debug cmake .. nmake setup tools for x86/debug mkdir x86_debug cd x86_debug cmake .. nmake So the various build-tree's for the configurations are separate subdirs inside your source-tree (you can also put them completely outside of your source-tree). So there's only 1 set of source/cmake files, but multiple sets of makefiles/buildfiles. Andreas -- Someone whom you reject today, will reject you tomorrow. ___ 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] [VS gen] Multiple configurations code
On Mon, Jul 26, 2010 at 4:35 PM, Olaf van der Spek olafvds...@gmail.com wrote: On Mon, Jul 26, 2010 at 10:31 PM, John Drescher dresche...@gmail.com wrote: You do not have multiple copies of the source. You have 1 copy of the source that you build in multiple trees. For me I build 32 and 64 bit for multiple compilers. They all share the same source tree but have different build trees. For example my source is in X:\CmakeBased My builds are in X:\32bit\vs.71 X:\32bit\vs.80 X:\32bit\vs.90 X:\64bit\vs.80 X:\64bit\vs.90 For each build I need to open the appropriate project file in the build tree. Isn't it easier to use the command line? If this is automated, it's not too bad. Does CMake provide a way to automate this? I do a mix of both. Additionally I have my projects generate a batch file in the build tree called Batch\install.bat calling that from a batch file for each dependent project causes all projects to build and install and at the end I get a NSIS installer for the main application. John ___ 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] [VS gen] Multiple configurations code
On 26. Jul, 2010, at 22:24 , Olaf van der Spek wrote: On Mon, Jul 26, 2010 at 10:12 PM, David Cole david.c...@kitware.com wrote: Is there a problem with multiple configures / build trees? No, not at all. We do this all the time. But again, I thought from your questions that you were trying to do it all in one build tree. I'm not familiar with the term build tree. Let's describe what I'd like: I've got a single CMakeLists.txt for a lib named xbt. I've got xbt.h and xbt.cpp. I'm using VS (2010). With a few simple commands, I should be able to build and package all possible configurations of this lib. In the ideal case, this would be cmake ., nmake ... or similar. It should not be necessary to modify CMakeLists or to have multiple copies of the source. Olaf A build tree is the top-level directory containing your generated project files. E.g I have the following directories: $HOME/Projects/ParaView - this is the source tree $HOME/Projects/ParaView-build-dbg64 - this is a 64-bit debug build tree $HOME/Projects/ParaView-build-rel64 - this is a 64-bit release build tree $HOME/Projects/ParaView-build-dbg32 - ...you get the picture... $HOME/Projects/ParaView-build-rel32 The first directory is the one containing all the sources. The other ones are various build trees for different configurations. Sometimes I have more, sometimes less. I have build trees linking against Qt4-Carbon and others linking against Qt4-Cocoa (this is on Mac OS X). So it would be entirely impossible for CMake to handle all these cases in one single build tree for me, after all I'm not just using different configurations and architectures, but also different libraries. It's not just a CMake problem, most IDE's wouldn't be able to do this. However, as you see, there's only one single source copy, and I never have to change the CMakeLists.txt file. Now, to your few simple commands, running CMake in a directory to create a build tree for a specific combination of compile-flags, architecture and libraries (and possibly other options) is a one-liner on the command line. Pretty simple if you ask me. You just have to get over the first hurdles, and invest some time. It will repay tenfold. 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] [VS gen] Multiple configurations code
On Mon, Jul 26, 2010 at 10:42 PM, Andreas Pakulat ap...@gmx.de wrote: I'm not familiar with the term build tree. That seems to be your problem here. The so-called source tree is the project folder on your disk containing the actual source files and the CMakeLists.txt files. The build-tree on the other hand is the folder in which you run cmake to generate the build files (Makefiles or whatever). Then it's a given that multiple build trees are needed. The usual way with Makefiles is to: setup tools for x64/release mkdir x64_release cd x64_release cmake .. nmake setup tools for x64/debug mkdir x64_debug cd x64_debug cmake .. nmake setup tools for x86/debug mkdir x86_debug cd x86_debug cmake .. nmake So the various build-tree's for the configurations are separate subdirs inside your source-tree (you can also put them completely outside of your source-tree). So there's only 1 set of source/cmake files, but multiple sets of makefiles/buildfiles. Makes sense, but that's certainly not something one wants to do by hand. In the VS case, it seems already possible to generate a project containing four different configurations. I'm asking for more configurations to be added. Olaf ___ 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] [VS gen] Multiple configurations code
On Mon, Jul 26, 2010 at 4:42 PM, John Drescher dresche...@gmail.com wrote: On Mon, Jul 26, 2010 at 4:35 PM, Olaf van der Spek olafvds...@gmail.com wrote: On Mon, Jul 26, 2010 at 10:31 PM, John Drescher dresche...@gmail.com wrote: You do not have multiple copies of the source. You have 1 copy of the source that you build in multiple trees. For me I build 32 and 64 bit for multiple compilers. They all share the same source tree but have different build trees. For example my source is in X:\CmakeBased My builds are in X:\32bit\vs.71 X:\32bit\vs.80 X:\32bit\vs.90 X:\64bit\vs.80 X:\64bit\vs.90 For each build I need to open the appropriate project file in the build tree. Isn't it easier to use the command line? If this is automated, it's not too bad. Does CMake provide a way to automate this? I do a mix of both. Additionally I have my projects generate a batch file in the build tree called Batch\install.bat calling that from a batch file for each dependent project causes all projects to build and install and at the end I get a NSIS installer for the main application. Here is one such batch file. X:\64bit\vc.90\install_la.bat call Lung\CT_Imaging\Batch\install.bat call Lung\BZ_Airway\Batch\install.bat call Lung\SCP_LS\Batch\install.bat call Lung\JPU_Lobe\Batch\install.bat call Qt\QtbasicUtils\Batch\install.bat call Qt\LungAnalysis\Batch\install.bat This is the same exact file I use for the 32 bit build under vs.80 as well. Since I used relative paths I just copied the batch file when I wanted to build 64bit. Note the build trees have the same structure as the source tree. John John ___ 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] [VS gen] Multiple configurations code
2010/7/26 Olaf van der Spek olafvds...@gmail.com: On Mon, Jul 26, 2010 at 10:12 PM, David Cole david.c...@kitware.com wrote: Is there a problem with multiple configures / build trees? No, not at all. We do this all the time. But again, I thought from your questions that you were trying to do it all in one build tree. I'm not familiar with the term build tree. You may have a look at this part of the FAQ: http://www.cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees Basically from CMake point of view, all **generated** files are in the build tree. Note that **generated** files does mean that those files are coming from a compilation step they may come from add_custom_command, execute_process etc... One thing that interest you in the first place is that the project file (or makefile etc...) is GENERATED so it ends up in the build tree. So having 2 separate build trees == having 2 separate project files. The main idea behind the source-tree / build-tree separation is that you may always delete the build tree because it may be regenerated from the source tree. This way if you use a VCS (CVS, svn git, etc...) you know that the VCS is only concerned by the source tree. A last thing is that a source tree may be shared by several build trees. Let's describe what I'd like: I've got a single CMakeLists.txt for a lib named xbt. I've got xbt.h and xbt.cpp. I'm using VS (2010). With a few simple commands, I should be able to build and package all possible configurations of this lib. In the ideal case, this would be cmake ., nmake ... or similar. It should not be necessary to modify CMakeLists or to have multiple copies of the source. Currently you don't need several copies of the sources, you only need several build trees configured with **differents** options from the SAME CMakeLists.txt. Is it more clear, stated like 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
[CMake] bash completion for cmake
Here comes a proposal for a bash completion for cmake. Should work with almost any cmake version because it's using cmake command to retrieve completion. Prerequisite: You should have bash-completion package installed. If you want to try you may either: 1) add the attache cmake file to /etc/bach_completion.d/ 2) source the file in your current (bash shell) $ . .cmake then $ cmake TABTAB offers first level completion $ cmake --help-command TABTAB offers second level completion I don't know how to handle third level for now. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org cmake Description: Binary data ___ 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] Subdirectories and FIND_LIBRARY routines
It looks like the thread Configuring targets software that isn't yet built also touches on the issue I'm facing. Hmm - wonder if I can work a trick with setting ZLIB_LIBRARY to just the name of the subdirectory library target... looks like I have some tests to run. CY ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.2-272-ge682e66
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 e682e668481b37cfcf22b348a99abf429f0c1b51 (commit)
via 7bf8dc1ac9d2c2430e247c2cfb54a6a4cb5f698a (commit)
from 4ee6fab20aa7451d94b7c01abcd728135746c9db (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=e682e668481b37cfcf22b348a99abf429f0c1b51
commit e682e668481b37cfcf22b348a99abf429f0c1b51
Merge: 4ee6fab 7bf8dc1
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jul 26 11:45:34 2010 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jul 26 11:45:34 2010 -0400
Merge topic 'ctest-git-flexibility' into next
7bf8dc1 ctest_update: Support .git file work trees
diff --cc Tests/CTestUpdateGIT.cmake.in
index f672a52,e1d345c..793b987
--- a/Tests/CTestUpdateGIT.cmake.in
+++ b/Tests/CTestUpdateGIT.cmake.in
@@@ -275,9 -259,14 +275,14 @@@ execute_process
WORKING_DIRECTORY \${TOP}\
COMMAND \${GIT}\ clone \${REPO}\ dash-source
)
+
+ # Test .git file.
+ file(RENAME \${TOP}/dash-source/.git\ \${TOP}/dash-source/repo.git\)
+ file(WRITE \${TOP}/dash-source/.git\ \gitdir: repo.git\n\)
+
execute_process(
WORKING_DIRECTORY \${TOP}/dash-source\
- COMMAND \${GIT}\ reset --hard master~2
+ COMMAND \${GIT}\ reset --hard ${revision1}
)
execute_process(
WORKING_DIRECTORY \${TOP}/dash-source\
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7bf8dc1ac9d2c2430e247c2cfb54a6a4cb5f698a
commit 7bf8dc1ac9d2c2430e247c2cfb54a6a4cb5f698a
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jul 26 11:40:20 2010 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Jul 26 11:40:20 2010 -0400
ctest_update: Support .git file work trees
Commit c3781efb (Support Git upstream branch rewrites, 2010-06-08)
assumed that .git/FETCH_HEAD exists inside the source tree. Fix the
implementation to handle a work tree using a .git file to link to its
repository. Use git rev-parse --git-dir to locate the real .git dir.
diff --git a/Source/CTest/cmCTestGIT.cxx b/Source/CTest/cmCTestGIT.cxx
index 41c1393..e44f81d 100644
--- a/Source/CTest/cmCTestGIT.cxx
+++ b/Source/CTest/cmCTestGIT.cxx
@@ -85,6 +85,54 @@ void cmCTestGIT::NoteNewRevision()
}
//
+std::string cmCTestGIT::FindGitDir()
+{
+ std::string git_dir;
+
+ // Run git rev-parse --git-dir to locate the real .git directory.
+ const char* git = this-CommandLineTool.c_str();
+ char const* git_rev_parse[] = {git, rev-parse, --git-dir, 0};
+ std::string git_dir_line;
+ OneLineParser rev_parse_out(this, rev-parse-out , git_dir_line);
+ OutputLogger rev_parse_err(this-Log, rev-parse-err );
+ if(this-RunChild(git_rev_parse, rev_parse_out, rev_parse_err))
+{
+git_dir = git_dir_line;
+}
+ if(git_dir.empty())
+{
+git_dir = .git;
+}
+
+ // Git reports a relative path only when the .git directory is in
+ // the current directory.
+ if(git_dir[0] == '.')
+{
+git_dir = this-SourceDirectory + / + git_dir;
+}
+#if defined(_WIN32) !defined(__CYGWIN__)
+ else if(git_dir[0] == '/')
+{
+// Cygwin Git reports a full path that Cygwin understands, but we
+// are a Windows application. Run cygpath to get Windows path.
+std::string cygpath_exe = cmSystemTools::GetFilenamePath(git);
+cygpath_exe += /cygpath.exe;
+if(cmSystemTools::FileExists(cygpath_exe.c_str()))
+ {
+ char const* cygpath[] = {cygpath_exe.c_str(), -w, git_dir.c_str(), 0};
+ OneLineParser cygpath_out(this, cygpath-out , git_dir_line);
+ OutputLogger cygpath_err(this-Log, cygpath-err );
+ if(this-RunChild(cygpath, cygpath_out, cygpath_err))
+{
+git_dir = git_dir_line;
+}
+ }
+}
+#endif
+ return git_dir;
+}
+
+//
bool cmCTestGIT::UpdateByFetchAndReset()
{
const char* git = this-CommandLineTool.c_str();
@@ -121,8 +169,13 @@ bool cmCTestGIT::UpdateByFetchAndReset()
// Identify the merge head that would be used by git pull.
std::string sha1;
{
- std::string fetch_head = this-SourceDirectory + /.git/FETCH_HEAD;
+ std::string fetch_head = this-FindGitDir() + /FETCH_HEAD;
std::ifstream fin(fetch_head.c_str(), std::ios::in | std::ios::binary);
+ if(!fin)
+{
+this-Log Unable to open fetch_head \n;
+return false;
+}
std::string line;
while(sha1.empty() cmSystemTools::GetLineFromStream(fin, line))
{
diff --git a/Source/CTest/cmCTestGIT.h b/Source/CTest/cmCTestGIT.h
[Cmake-commits] CMake branch, master, updated. v2.8.2-120-g13d6863
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 13d686331e5bf410290dee530051987161173d86 (commit) from c457288767f606c8e5f7691ba1369543109304a5 (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=13d686331e5bf410290dee530051987161173d86 commit 13d686331e5bf410290dee530051987161173d86 Author: KWSys Robot kwro...@kitware.com AuthorDate: Tue Jul 27 00:01:10 2010 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Tue Jul 27 00:10:06 2010 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index cb7ece3..0c4430a 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2010) SET(KWSYS_DATE_STAMP_MONTH 07) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 26) +SET(KWSYS_DATE_STAMP_DAY 27) --- 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
