[CMake] How to on multiple RPM packages
Hi, We are currently looking forward to migrate to CMake and we are struggling a bit with cpack. The first project we migrate provides a executable binary but also a library and its headers. I do not find an example on how to provide separate RPM's for them; one for the binary and one for the headers+library. The required results (rough example): - foo-1.2.3.4-1.x86_64.rpm - libfoo-1.2.3.4-1.x86.64.rpm Anybody who can help us with this? Regards, Thomas -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How to on multiple RPM packages
Hi Thomas, CPack RPM may generate several packages at once if you define COMPONENTS in your project. The behavior of CPackRPM w.r.t. COMPONENT packaging depends on Some CPack COMPONENT generic variables, namelly: CPACK_RPM_COMPONENT_INSTALL --> this one must be set to ON CPACK_COMPONENTS_* variables see: https://cmake.org/cmake/help/v3.4/module/CPackComponent.html The bunch of RPM specific variables CPACK_RPM__* variables see https://cmake.org/cmake/help/v3.4/module/CPackRPM.html More references (some may be outdated) there: https://cmake.org/Wiki/CMake:Component_Install_With_CPack https://cmake.org/Wiki/CMake:CPackPackageGenerators#RPM_.28Unix_Only.29 http://cmake.3232098.n2.nabble.com/CPack-RPM-with-COMPONENTS-packaging-td7583729.html 2016-01-15 9:05 GMT+01:00 Thomas Lehmann : > > Hi, > > We are currently looking forward to migrate to CMake and > we are struggling a bit with cpack. > > The first project we migrate provides a executable binary but also > a library and its headers. > > I do not find an example on how to provide separate RPM's > for them; one for the binary and one for the headers+library. > The required results (rough example): > > - foo-1.2.3.4-1.x86_64.rpm > - libfoo-1.2.3.4-1.x86.64.rpm > > Anybody who can help us with this? > > Regards, > Thomas > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Eric -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How to on multiple RPM packages
Hm I've accidentally dropped cmake mailing list when replying before... Sorry about that. > Im using "bin" and "devel" as component names. I tried next with upper and > lower case in the properties but no difference. > it's about what you see in the RPM header using "rpm -qlip name.rpm" ... Component name changing patch was already applied in git and will be available in next CMake release. Until then you could patch your CPackRPM.cmake file (comes with CMake installation) with this patch: https://cmake.org/gitweb?p=cmake.git;a=commit;h=c926efa > a) Also it is documented CPACK_RPM_DEVEL_PACKAGE_DESCRIPTION has no > effect I always get "This is an installer created using CPack > (https://cmake.org). No additional installation instructions provided." > b) Same for summary. I always get "NGSelector built using CMake" It's possible that you are using an older version of CPack that doesn't support this per component feature. This was introduced in CPack version 3.2. Before only non component versions of description of summary were supported. > c) I cannot specify different groups like "Application" and "Library"? Fix is the same patch as for name. > d) Can I get rid of the "-bin" in the RPM file name? Not at the moment... There are pending bug reports for this. You could however use above patch to change package name and rename the file name manually after generation. Regards, Domen -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How to on multiple RPM packages
I've accidentally dropped the mailing list in reply: > I do not find an example on how to provide separate RPM's > for them; one for the binary and one for the headers+library. > The required results (rough example): > > - foo-1.2.3.4-1.x86_64.rpm > - libfoo-1.2.3.4-1.x86.64.rpm You have to provide COMPONENT and name in install commands: install(TARGETS prog DESTINATION foo COMPONENT binary) install(FILES someheader.hpp DESTINATION foo COMPONENT headersandlibs) set that you wish to package components: set(CPACK_RPM_COMPONENT_INSTALL "ON") and enable RPM packaging generator: set(CPACK_GENERATOR "RPM") You can also set other per component properties to be used by CPackRPM. See the documentation here: https://cmake.org/cmake/help/v3.4/module/CPackRPM.html All of this should be done before calling: include(CPack) Hope this helps. Regards, Domen -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] using macros
Yes, indeed. Yikes, thanks for this!
On Thu, Jan 14, 2016, 17:21 Petr Kmoch wrote:
> Hi Owen.
>
> As a sanity check, the definition of the macro in the toplevel CMakeList
> comes *before* the add_subdirectory() command for the one which errors out,
> right?
>
> Petr
>
> On Thu, Jan 14, 2016 at 8:25 AM, Owen Hogarth II
> wrote:
>
>> I am trying to use a macro to enable c99 in some of my cmake modules.
>>
>> In the top level cmake file I add this macro
>>
>> macro(use_c99)
>> if (CMAKE_VERSION VERSION_LESS "3.1")
>> if (CMAKE_C_COMPILER_ID STREQUAL "GNU")
>> set (CMAKE_C_FLAGS "--std=gnu99 ${CMAKE_C_FLAGS}")
>> endif ()
>> else ()
>> set (CMAKE_C_STANDARD 99)
>> endif ()
>> endmacro(use_c99)
>>
>> then in another CMakeLists.txt file I add
>> use_c99()
>>
>> but I get this error:
>>
>> CMake Error at source/internal_src/cube/CMakeLists.txt:1 (use_c
>> 99):
>> Unknown CMake command "use_c99".
>>
>> why am I unable to use the macro? My main cmake is using 3.0.2 from
>> debian repository.
>>
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
>You can not change the generator. It is better to remove the entire >build tree. Out of source builds are a best practice with CMake. Once >a build tree has been configured with one compiler, it must be >completely removed to change to a new compiler Clearly, "can not" is incorrect, since I did. "must be" seems also incorrect. It seems like the developers don't understand about 32-bit vs. 64-bit builds, or don't intend for this tool to be used with software that is a product. Determining that after painstakingly configuring all of the build options, the user must throw it all away in order to build for the other "bitness", seems wrong. Almost anyone that is intending to build software that can be installed (without the end user having to build it from source every time, that way lies madness) needs to produce a 32-bit and a 64-bit package these days. >CMake creates VS projects that should >work to build the project that is the goal. I don't understand about >make and MSVS, CMake can create makefiles or ninja files if that is what >you are talking about. The VC project files produced by the CMAKE system for OpenCV use absolute paths and use them throughout the project files, rather than defining things at top-level and then using predetermined macros like $(TargetDir) and $(TargetName), to say nothing of conveniences like $(PlatformTarget). I don't really know if that is inherent in how CMAKE generates the project files or if there is a way to produce more easily maintainable project files, but every time I have to utilize a project that involves CMAKE I cringe because of the ugly project files it produces. The makefiles produced have been the same way, with the same absolute paths occurring over and over in the file. I do not like this, as it makes the project files/makefiles difficult to debug or maintain. Having expressed this dislike here, I feel much better and will probably not think about this much in the future, up until the point I have to update to a new version of a library such as OpenCV or HDF5. Then I will cringe; pick through all of the settings and generate the makefiles/project files again; debug the results for a day or so until the builds actually, you know, work; and then do my little edit-and-regenerate trick to build for the other architecture. Because the design of CMAKE does not recognize that the results of "try-compile" tests are orthogonal to settings like "build module A" or "build shared libraries", so that the latter should not depend upon the former. -- View this message in context: http://cmake.3232098.n2.nabble.com/Changing-the-the-current-generator-in-CMake-GUI-tp7587876p7592499.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] ExternalProject_Add support for git clone -o option
Hello all, I am reading through the ExternalProject source for 3.2 at the moment (if updating to 3.4 is the answer, great!) and trying to determine if there is support for the -o option when using a git repository. Has anyone accomplished this? I would like to have names other than "origin" Cheers, Adam -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] ExternalProject_Add support for git clone -o option
Why would you like to have names other than origin? I am struggling to think of a use case for this, seeing as you never directly interact with the cloned repository. I don't even think it's safe to assume that a git repository is involved at all, for all you know it could be changed to just download the code and never even involve git. (Maybe it is guaranteed somewhere but I don't see such a guarantee in the documentation) On Fri, Jan 15, 2016 at 10:03 AM, Adam Rankin wrote: > Hello all, > > > > I am reading through the ExternalProject source for 3.2 at the moment (if > updating to 3.4 is the answer, great!) and trying to determine if there is > support for the –o option when using a git repository. > > > > Has anyone accomplished this? I would like to have names other than “origin” > > > > Cheers, > > Adam > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] ExternalProject_Add support for git clone -o option
My use case is for forked repositories and sending pull requests upstream. In this case "origin" is ambiguous as manage both remotes and I would like to give the cloned repository a more accurate name. Cheers, Adam -Original Message- From: Nicholas Braden [mailto:nicholas11bra...@gmail.com] Sent: Friday, January 15, 2016 12:02 PM To: Adam Rankin Cc: cmake@cmake.org Subject: Re: [CMake] ExternalProject_Add support for git clone -o option Why would you like to have names other than origin? I am struggling to think of a use case for this, seeing as you never directly interact with the cloned repository. I don't even think it's safe to assume that a git repository is involved at all, for all you know it could be changed to just download the code and never even involve git. (Maybe it is guaranteed somewhere but I don't see such a guarantee in the documentation) On Fri, Jan 15, 2016 at 10:03 AM, Adam Rankin wrote: > Hello all, > > > > I am reading through the ExternalProject source for 3.2 at the moment > (if updating to 3.4 is the answer, great!) and trying to determine if > there is support for the –o option when using a git repository. > > > > Has anyone accomplished this? I would like to have names other than “origin” > > > > Cheers, > > Adam > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] ExternalProject_Add support for git clone -o option
To elaborate on my reply: I do indeed interact with the repository after it's cloned (as per my previous email). With regards to implementation, I have implemented it such that the git remote name is only involved if git is chosen as the source of choice, in much the same manner as the git_tag implementation. My implementation makes the git remote name completely optional and defaults to "origin". Regards, Adam -Original Message- From: Nicholas Braden [mailto:nicholas11bra...@gmail.com] Sent: Friday, January 15, 2016 12:02 PM To: Adam Rankin Cc: cmake@cmake.org Subject: Re: [CMake] ExternalProject_Add support for git clone -o option Why would you like to have names other than origin? I am struggling to think of a use case for this, seeing as you never directly interact with the cloned repository. I don't even think it's safe to assume that a git repository is involved at all, for all you know it could be changed to just download the code and never even involve git. (Maybe it is guaranteed somewhere but I don't see such a guarantee in the documentation) On Fri, Jan 15, 2016 at 10:03 AM, Adam Rankin wrote: > Hello all, > > > > I am reading through the ExternalProject source for 3.2 at the moment > (if updating to 3.4 is the answer, great!) and trying to determine if > there is support for the –o option when using a git repository. > > > > Has anyone accomplished this? I would like to have names other than “origin” > > > > Cheers, > > Adam > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
On Fri, Jan 15, 2016 at 8:26 AM, mozzis wrote: > > Clearly, "can not" is incorrect, since I did. "must be" seems also > incorrect. Changing Generator is not exactly the same idea of what you're doing 1) If you actually chaned from VS 2010 to VS2012 or more radically to MinGW Makefiles and redid the build, you would have only partially correct results. And actually even changing the bitness you already have products built (.obj files) which won't be retriggered to compile to some other flavor since the .obj will aready be newer than the source so you'd have to do a rebuild. > It seems like the developers don't understand about 32-bit vs. 64-bit > builds, or don't intend for this tool to be used with software that is a > product. Determining that after painstakingly configuring all of the build > options, the user must throw it all away in order to build for the other > "bitness", seems wrong. Almost anyone that is intending to build software > that can be installed (without the end user having to build it from source > every time, that way lies madness) needs to produce a 32-bit and a 64-bit > package these days. > This is 2 different packages, 2 different targets, (4 if you distribute debug versions also). The packing stage will really expect separate targets. However, I solve this by making simple 'makeit.bat' scripts. copy and replace the generator and go. But it also sounds like you're trying to get Cmake to play with existing builds instead of treating cmake as the primary build system. I fought with this a bit and was discusted myself in the lack of conformance to default project $(outputdir)/$(targetname) stuff. Was expecting to use cmake to generate projects I could then maintain as visual studio projects myself. But I was already supporting a Make system for targeting linux/mingw/watcom/lcc having bit the bullet and converted exising visual studio projects o cmakelists and migraing to using cmake as a primary tool has made life a lot simpler. I like that I can now just add_subdirectory( ../../../bullet3 Bullet3 ) and then have those libraries available to just specify target_link_libraryes( physics_demo bullet ) or openal or .. Kind of wish the whole world would switch now that cmake is quite mature. (back in version 1.4 something it still seemed insufficient for some things) Yes, you often cannot just build a target and run it (wish it would build into a single solution relative output directory instead of project relative, which would make running in the debugger just so much easier ) BUt I've included INSTALL() rules and just always build the INstall target which only builds the things that have changed and copies only those things to the output, and setup Debugging properties on the install project to launch the thing I want to (I have a core library with a half dozen utilties, and a binaries library that outputs probably some 60 simple tools ) (CMAKE_INSTALL_PREFIX doesn't have to target /program files but rather can just target 'otuput' which is relative to the CMAKE_BINARY_DIR ) for testing/build processes... then Package target (with NSIS Support) is pretty easy to add and get target packages. But I target primarily MinGW, Linux, Android, VS 2015(now) OpenWatcom... each of these has their own additional libraries, and ways of generating code which are in most cases mutually exclusive, so even attempting to change generator in CMakeCache is not even a thought (yes, think I did try to do that at the beginning also) --- one makeit.bat generated by a cmakelists to build all targets --- "c:/tools/unix/cmake/bin/cmake.exe" -G "Visual Studio 14 2015" -T "v140" "M:/sack/cmake_all/.." -DCMAKE_BUILD_TYPE=release -DCMAKE_INSTALL_PREFIX=C:/General/Build/sack-vs14/release_out/core -DBUILD_MONOLITHIC=OFF -DBUILD_EXTRAS=ON -D__NO_ODBC__=0FF -DNEED_FREETYPE=ON -DNEED_JPEG=ON -DNEED_PNG=ON -DNEED_ZLIB=ON c:\tools\unix\cmake\bin\cmake.exe --build . --config "release" --target "INSTALL" -- /m:4 /v:m --- Using the cmake --build unifies having to call MSBuild or Make of MingW32Make or WMake as appropriate for the generator in question (although the arguments do change based on the genartor for specifying build-tool specific options like /m:4 or /j 4(make) ) >>CMake creates VS projects that should >>work to build the project that is the goal. I don't understand about >>make and MSVS, CMake can create makefiles or ninja files if that is what >>you are talking about. > > The VC project files produced by the CMAKE system for OpenCV use absolute > paths and use them throughout the project files, rather than defining things > at top-level and then using predetermined macros like $(TargetDir) and > $(TargetName), to say nothing of conveniences like $(PlatformTarget). I > don't really know if that is inherent in how CMAKE generates the project > files or if there is a way to produce more easily maintainable project > files, but every time I have to utilize a project that involves CMAKE
Re: [CMake] Changing the the current generator in CMake GUI
On 1/15/2016 11:26 AM, mozzis wrote: You can not change the generator. It is better to remove the entire build tree. Out of source builds are a best practice with CMake. Once a build tree has been configured with one compiler, it must be completely removed to change to a new compiler Clearly, "can not" is incorrect, since I did. "must be" seems also incorrect. You can do it by changing the CMakeCache.txt file, but it won't work in the general case. You should put them in separate directories: build-32 and build-64. It seems like the developers don't understand about 32-bit vs. 64-bit builds, or don't intend for this tool to be used with software that is a product. Determining that after painstakingly configuring all of the build options, the user must throw it all away in order to build for the other "bitness", seems wrong. Almost anyone that is intending to build software that can be installed (without the end user having to build it from source every time, that way lies madness) needs to produce a 32-bit and a 64-bit package these days. You can build both 32 and 64 from the same SOURCE tree, just not the same build tree. src build32 (cmake ../src -G"Visual Studio 10 2010") build64 (cmake ../src -G"Visual Studio 10 2010 Win64") You seem to be trying to reuse the same build tree for different builds which is not a supported use case. I think if you stopped doing that your life might get easier when working with CMake projects. -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
Bill Hoffman wrote: You can do it by changing the CMakeCache.txt file, but it won't work in the general case. You should put them in separate directories: build-32 and build-64. You can build both 32 and 64 from the same SOURCE tree, just not the same build tree. build32 (cmake ../src -G"Visual Studio 10 2010") build64 (cmake ../src -G"Visual Studio 10 2010 Win64") You seem to be trying to reuse the same build tree for different builds which is not a supported use case. I think if you stopped doing that your life might get easier when working with CMake projects. You can do both in the same solution/projects with the Microsoft fork of CMake, but it's not a general solution, and it doesn't handle different settings for 32 bit and 64 bit. Because of that, they're "not pushing too hard" for it to be in mainline CMake. https://cmake.org/pipermail/cmake/2015-August/061346.html -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
On 1/15/2016 2:41 PM, Greg Marr wrote: You can do both in the same solution/projects with the Microsoft fork of CMake, but it's not a general solution, and it doesn't handle different settings for 32 bit and 64 bit. Because of that, they're "not pushing too hard" for it to be in mainline CMake. https://cmake.org/pipermail/cmake/2015-August/061346.html Yes, and things like CMAKE_SIZEOF_VOID_P would not have valid values. However, if you want cmake builds to work, you should never change the generator in a CMakeCache.txt file, it is going to more often than not cause problems. A build tree should be configured with one generator and if you need another generator you should use a different directory and a different build tree sharing the same source tree. -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
Bill Hoffman wrote: >On 1/15/2016 2:41 PM, Greg Marr wrote: >> You can do both in the same solution/projects with the Microsoft fork >> of CMake, but it's not a general solution, and it doesn't handle >> different settings for 32 bit and 64 bit. > >Yes, and things like CMAKE_SIZEOF_VOID_P would not have valid values. Correct, so if you require different settings based on that value, you can't use this solution. However, if you never look at it, then this may work for you. > However, if you want cmake builds to work, you should never change the > generator in a CMakeCache.txt file, it is going to more often than not > cause problems. A build tree should be configured with one generator > and if you need another generator you should use a different directory > and a different build tree sharing the same source tree. Absolutely, that's why this is a single generator and is generated once. Unfortunately, the different settings limitation of this solution is rather...limiting. It would be really nice if this could be made to work with different settings for the different CPU architectures (mostly just library paths for my past uses), just like native Visual Studio, XCode, Eclipse, and Android Studio projects do, but that would apparently be a very major change. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Changing the the current generator in CMake GUI
Well, CMAKE is the thing that is conflating this idea of a "generator" (which is clearly a concept in CMAKE's own domain of "build configuration generator") with the idea of "platform" or "architecture" (which is a concept in the domain of certain kinds of build tools, such as a C compiler.) It would be healthier if platform/arch were broken out as a separate item in CMAKE, i.e. CMAKE recognizes that some build tools have this concept, but is (possibly) agnostic about how it is represented. I assume that it is not really possible to do so in the config files that drive CMAKE at present, only because I have never seen it done and did not find it when I went looking. Instead, that information is scattered across several files in the CMakeFiles folder. Thank you for the hints and examples about using batch files. I may try to implement that scheme for building support libraries that come dependent on CMake. But I don't believe that I will ever use CMake for any product I am in control of, mainly because I have seen what an unmaintainable mess it creates for project files. And at least partly as a result, since there is no direct comprehension on the part of the developer/maintainer as to the project file structure, it becomes impossible to adequately manage that structure, so making large-scale improvements is nearly impossible without starting over from scratch. In addition, the build process becomes way inefficient. For example, once when I was really at loose ends due to a management blow-up, I reworked the build system for HDF5 on Visual Studio so it had "normal" project files that could be used to build for various platforms and configurations. The resulting build time was cut by a factor of 5, plus it became much easier (for me anyways) to be able to do things like change the output file names based on platform, something I have so far found impossible to do with CMake. [Once again, it really has no concept of this.] I would do the same thing for OpenCV, but it is ten times worse than HDF5 in this regard. For instance, apparently project files are modified as part of the MSVS build process, so that Visual Studio always complains about project files needing to be reloaded after a build. This is a recipe for mysterious bugs that you will never be able to fix. I have created/maintained multi-platform projects, and I find that the effort needed to produce efficient, readable makefiles for each platform is worth it. Once done, I can change the platform or the library type or similar parameters by changing one switch in each platform's makefile. Plus there are fewer gotchas at runtime, as not querying the build environment for every build ensures more consistent behavior in the binaries I am going to distribute. Thanks again to all for the comments on this thread. It is good to know that development continues on this tool. At some point, it may become more interesting for me. From: J Decker [via CMake] [mailto:ml-node+s3232098n7592504...@n2.nabble.com] Sent: Friday, January 15, 2016 1:10 PM To: Morris Maynard Subject: Re: Changing the the current generator in CMake GUI On Fri, Jan 15, 2016 at 8:26 AM, mozzis <[hidden email]> wrote: > > Clearly, "can not" is incorrect, since I did. "must be" seems also > incorrect. Changing Generator is not exactly the same idea of what you're doing 1) If you actually chaned from VS 2010 to VS2012 or more radically to MinGW Makefiles and redid the build, you would have only partially correct results. And actually even changing the bitness you already have products built (.obj files) which won't be retriggered to compile to some other flavor since the .obj will aready be newer than the source so you'd have to do a rebuild. > It seems like the developers don't understand about 32-bit vs. 64-bit > builds, or don't intend for this tool to be used with software that is a > product. Determining that after painstakingly configuring all of the build > options, the user must throw it all away in order to build for the other > "bitness", seems wrong. Almost anyone that is intending to build software > that can be installed (without the end user having to build it from source > every time, that way lies madness) needs to produce a 32-bit and a 64-bit > package these days. > This is 2 different packages, 2 different targets, (4 if you distribute debug versions also). The packing stage will really expect separate targets. However, I solve this by making simple 'makeit.bat' scripts. copy and replace the generator and go. But it also sounds like you're trying to get Cmake to play with existing builds instead of treating cmake as the primary build system. I fought with this a bit and was discusted myself in the lack of conformance to default project $(outputdir)/$(targetname) stuff. Was expecting to use cmake to generate projects I could then maintain as visual studio projects myself. But I was already supporting a Make system for targeting
