Re: [cmake-developers] Generating files at generate-time
Brad King wrote: On 05/02/2013 01:44 PM, Stephen Kelly wrote: Brad King wrote: Make it an error if different *content* will be written to the same file name by different configurations. Generate for all configs into per-config temp files. Then identify all files that map to a single name according to the OUTPUT genex and make sure they are the same. I don't think that requires writing for all configs to temp files. I can write the first file if it doesn't exist, and for subsequent configs, compare the evaluated content with the existing content in the file. Yes, that should work too. Note that for the first config that evaluates to a specific output you should write that file unconditionally (or as copy-if-different). It should ignore existing content for comparison purposes because the file could exist from a previous run of CMake. Ok, I've updated my genex-evaluate-file branch with an implementation which I'm fairly happy with. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] INTERFACE_LIBRARY target type
Brad King wrote: On 05/02/2013 11:26 AM, Stephen Kelly wrote: Perhaps we could do aliasing with a target property instead? add_library(foo SHARED foo.cpp) set_property(TARGET foo APPEND PROPERTY ALIAS_NAME KF5::foo) No, I like to be able to say that all logical target names are created by an add_* call. Actually your point about scopes of target names means that ALIAS targets should be scoped like IMPORTED targets since their purpose is to self-import. That is an argument for ALIAS targets to be built on IMPORTED targets. I wouldn't say the primary purpose is to self-import, and therefore they should behave as IMPORTED targets. Their primary purpose is to be an alias for another target. This might need some deeper consideration. I like that IMPORTED targets can not be re-exported, and I would expect the same for the INTERFACE_LIBRARY type. How should a project define an interface library and get CMake to put it in a targets file through install(EXPORT) or export()? I don't think I understand the question. It should be the same as for any other target. add_library(iface INTERFACE) export(TARGETS iface) results in add_library(iface INTERFACE IMPORTED) # ... I think that's the conclusion you reach below too. Shouldn't header-only libraries be able to work like that? Yes. IMPORTED targets also have a different scope to non-imported targets. I'd expect that if I find_package somewhere and a KF5::iface INTERFACE_LIBRARY results, that follows the same scope rules as KF5::KArchive. Perhaps IMPORTED and INTERFACE are orthogonal. Yes, that's the way I've been thinking of them. One could import an interface library defined by another project. I'll retract my previous assertion that IMPORTED targets should always refer to files. Yes. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] INTERFACE_LINK_LIBRARIES property?
Hi, Last year we discussed the addition of a INTERFACE_LINK_LIBRARIES property to replace the (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_CONFIG)? properties. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5398 After a lot of back-and-forth, I bypassed the issue of that property by adding generator expression support to the (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_CONFIG)? properties instead. Part of the policy under discussion relied on an assumption that the LINK_LIBRARIES property does not contain generator expressions, but that assumption won't be true anymore after 2.8.11 is released. I think that related to the fact that if LINK_LIBRARIES contains generator expressions, and the link implementation is the link interface, then only the new INTERFACE_LINK_LIBRARIES should be populated and not the old interface properties (because they couldn't handle the genexes). So, if we still want to introduce INTERFACE_LINK_LIBRARIES, we may need to re-think that part. Alternatively we could decide to finally drop the INTERFACE_LINK_LIBRARIES property. If we do introduce it, I'd want to get it in before the INTERFACE_LIBRARY so that that target type only supports the new property. Comments? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] INTERFACE_LIBRARY target type
On Friday 03 May 2013, Stephen Kelly wrote: Brad King wrote: On 05/02/2013 11:26 AM, Stephen Kelly wrote: Perhaps we could do aliasing with a target property instead? add_library(foo SHARED foo.cpp) set_property(TARGET foo APPEND PROPERTY ALIAS_NAME KF5::foo) No, I like to be able to say that all logical target names are created by an add_* call. Actually your point about scopes of target names means that ALIAS targets should be scoped like IMPORTED targets since their purpose is to self-import. That is an argument for ALIAS targets to be built on IMPORTED targets. I wouldn't say the primary purpose is to self-import, and therefore they should behave as IMPORTED targets. Their primary purpose is to be an alias for another target. Ok. So why is this needed in cmake ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] Building multiple configurations with Xcode?
Hi, I am investigating https://bugreports.qt-project.org/browse/QTBUG-30938 and I wanted to see what cmake exports when it export() is used with a framework target. I created a shared library and ran cmake with -GXcode, then cmake --build ., but it seems to only create a release library. I thought Xcode generated rules for multiple configurations? Do I need to do something extra for that to be done? Thanks, Steve. cmake_minimum_required(VERSION 2.8) project(cmake_framework_target) include(GenerateExportHeader) set(CMAKE_INCLUDE_CURRENT_DIR ON) add_library(other SHARED lib.cpp) generate_export_header(other) set_property(TARGET other PROPERTY FRAMEWORK 1) install(TARGETS other RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib FRAMEWORK DESTINATION framework ) -- 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] Building multiple configurations with Xcode?
Stephen Kelly wrote: and I wanted to see what cmake exports when it export() is used with a framework target. I created a shared library and ran cmake with -GXcode, then cmake --build ., but it seems to only create a release library. I thought Xcode generated rules for multiple configurations? Do I need to do something extra for that to be done? I found that I need to use cmake . --build --config Debug or --config Release to build a particular configuration. However, the debug and release names are the same. I also ran cmake with -DCMAKE_DEBUG_POSTFIX=Debug but that didn't make any difference. I'm not familiar with the way things are done on mac. Any ideas? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Recursive object libraries
Thanks very much for adding add_library(OBJECT); it's Just the Thing™ for organising source files that go into large libraries. It seems that I can't use it recursively, however: Only executables and non-OBJECT libraries may reference target objects. I'd like to use the same mechanism to organise a more-than-single-level hierarchy of source directories; is this / will this in the future be possible? Jon -- Jonathan Anderson Research Associate Computer Laboratory University of Cambridge +44 (1223) 763747 jonathan.ander...@cl.cam.ac.uk -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake installation problems
Hello I am trying to install CMake (version 2.6.4) prior to the installation of Geant4 in my system (Scientific linux cern 5.3). As I give the command cmake -DCMAKE_INSTALL_PREFIX=/home/geant4/geant4.9.5-install /home/geant4/geant4.9.5/cmake-2.6.4 it is showing $ Curses libraries were not found. Curses GUI for CMake will not be built. -- Configuring done -- Generating done -- Build files have been written to: /home/geant4/geant4.9.5/cmake-2.6.4 Any suggestion to solve this problem would be appreciative. Thanks in advance. Prasun Sarkar In reply It looks like you do not have the Curses headers/libraries installed on the system. However, it is reporting that configuration/generation was successful, so you should be able to build CMake fine, just that you won't get the ccmake Curses interface. If you do want ccmake , then you'll need to install the relevant packages - on SLC, I think these are rpms ncurses and ncurses-devel . You could also try using the Linux binary distributed by Kitware ( http://cmake.org/cmake/resources/software.html) . Hope that helps, though note that we can't in general provide support for installing CMake itself. If you have further questions on this, I would direct them to the relevant CMake mailing list ( http://www.cmake.org/cmake/help/mailing.html) . Cheers, Ben. Hello I tried to install the ncurses-devel. I searched for the Scientific Linux Cern (SLC) version 5.3 at http://rpmfind.net/linux/rpm2html/search.php?query=ncurses-devel but could not find that version. I have already used the linux binary distributed by kitware for cmake version 2.6.4. ( http://cmake.org/cmake/resources/software.html ) Any additional comments to install the Curses libraries would be appreciated. Thanking you in advance. Prasun Sarkar -- 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] Building multiple configurations with Xcode?
Stephen Kelly wrote: or --config Release to build a particular configuration. However, the debug and release names are the same. I also ran cmake with -DCMAKE_DEBUG_POSTFIX=Debug but that didn't make any difference. This makes a difference for non-frameworks, but does not make a difference if the FRAMEWORK property is true. Is it possible to build multi-config frameworks with cmake at all? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake installation problems
2013/5/3 Prasun Sarkar prasun...@gmail.com: Hello I am trying to install CMake (version 2.6.4) prior to the installation of Geant4 in my system (Scientific linux cern 5.3). As I give the command cmake -DCMAKE_INSTALL_PREFIX=/home/geant4/geant4.9.5-install /home/geant4/geant4.9.5/cmake-2.6.4 Why would you like to install such ancient version of cmake? Unless you have good reason to do so you should install 2.8.x series. 2.8.10.2 being the latest release. it is showing $ Curses libraries were not found. Curses GUI for CMake will not be built. -- Configuring done -- Generating done -- Build files have been written to: /home/geant4/geant4.9.5/cmake-2.6.4 Any suggestion to solve this problem would be appreciative. [...] It looks like you do not have the Curses headers/libraries installed on the system. However, it is reporting that configuration/generation was successful, so you should be able to build CMake fine, just that you won't get the ccmake Curses interface. If you do want ccmake , then you'll need to install the relevant packages - on SLC, I think these are rpms ncurses and ncurses-devel . That's a good answer did you simply try $ yum install ncurses-devel I guess the already configured repository should work? You could also try using the Linux binary distributed by Kitware (http://cmake.org/cmake/resources/software.html) This is a good advice as well. Did you try any of the pre-compiled binaries? [...] I have already used the linux binary distributed by kitware for cmake version 2.6.4. ( http://cmake.org/cmake/resources/software.html ) So what is the problem with that version? Any additional comments to install the Curses libraries would be appreciated. This question is not cmake-specific, may be you should ask on SLC support channels (forum, mailing list, ...). https://www.scientificlinux.org/community/ -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.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] Building multiple configurations with Xcode?
Stephen Kelly wrote: Is it possible to build multi-config frameworks with cmake at all? I also notice that the Framework unit test uses set_target_properties(foo PROPERTIES FRAMEWORK TRUE DEBUG_POSTFIX -d ) but the debug file is called 'foo', not 'foo-d'. If I use cmake --build . --target install --config Debug cmake --build . --target install --config Release the debug and release versions overwrite each other. Does this mean it has always been broken? Has no one ever tried to create a framework using cmake? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building multiple configurations with Xcode?
- Original Message - Stephen Kelly wrote: Is it possible to build multi-config frameworks with cmake at all? I also notice that the Framework unit test uses set_target_properties(foo PROPERTIES FRAMEWORK TRUE DEBUG_POSTFIX -d ) but the debug file is called 'foo', not 'foo-d'. If I use cmake --build . --target install --config Debug cmake --build . --target install --config Release the debug and release versions overwrite each other. Does this mean it has always been broken? Has no one ever tried to create a framework using cmake? In the build tree, I would expect foo not foo-d for the debug framework. And in the build tree, it is possible to differentiate the release from debug simply by having two foo.framework/foo. One will be in the Release folder and one in the Debug folder, and a Debug build will use the one from the Debug folder, while the release build will use the one from the Release folder. For the install tree, I don't see how it is known which configurations will be installed. If there was some way to know both Release and Debug were going to be installed, then it could be known at that point to rename the debug file to foo-d. Clint -- 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] Building multiple configurations with Xcode?
clin...@elemtech.com wrote: - Original Message - Stephen Kelly wrote: Is it possible to build multi-config frameworks with cmake at all? I also notice that the Framework unit test uses set_target_properties(foo PROPERTIES FRAMEWORK TRUE DEBUG_POSTFIX -d ) but the debug file is called 'foo', not 'foo-d'. If I use cmake --build . --target install --config Debug cmake --build . --target install --config Release the debug and release versions overwrite each other. Does this mean it has always been broken? Has no one ever tried to create a framework using cmake? In the build tree, I would expect foo not foo-d for the debug framework. And in the build tree, it is possible to differentiate the release from debug simply by having two foo.framework/foo. One will be in the Release folder and one in the Debug folder, and a Debug build will use the one from the Debug folder, while the release build will use the one from the Release folder. That indeed appears to be what happens. For the install tree, I don't see how it is known which configurations will be installed. I'm not familiar with xcode, so I assumed that if you install it would install all configurations, or you would specify which you want to install. When I use the command line I use cmake --build . --target install --config Debug so it is specified. So, I don't know what you mean here. Can you be more specific, keeping in mind I don't know xcode? Assuming there is some unavoidable reason that the configuration is not known when installing, does that mean that frameworks which contain a foo and a foo_debug can not be created by cmake? I left a comment on the original Qt bug above that he should look into using DYLD_IMAGE_SUFFIX. Is that right? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building multiple configurations with Xcode?
- Original Message - clin...@elemtech.com wrote: - Original Message - Stephen Kelly wrote: Is it possible to build multi-config frameworks with cmake at all? I also notice that the Framework unit test uses set_target_properties(foo PROPERTIES FRAMEWORK TRUE DEBUG_POSTFIX -d ) but the debug file is called 'foo', not 'foo-d'. If I use cmake --build . --target install --config Debug cmake --build . --target install --config Release the debug and release versions overwrite each other. Does this mean it has always been broken? Has no one ever tried to create a framework using cmake? In the build tree, I would expect foo not foo-d for the debug framework. And in the build tree, it is possible to differentiate the release from debug simply by having two foo.framework/foo. One will be in the Release folder and one in the Debug folder, and a Debug build will use the one from the Debug folder, while the release build will use the one from the Release folder. That indeed appears to be what happens. But, I personally don't see a problem with there being a foo.framework/foo and a foo-d.framework/foo-d. At install time, they would not overwrite each other and the export file would need to list both of them. For the install tree, I don't see how it is known which configurations will be installed. I'm not familiar with xcode, so I assumed that if you install it would install all configurations, or you would specify which you want to install. Xcode works in one configuration at a time. The install target is the same way, by installing only one configuration at a time. When I use the command line I use cmake --build . --target install --config Debug so it is specified. That one configuration was specified, yes. But it isn't known if the Release one will also be installed. If it is known they are both being installed, and one wanted them to both go into the same framework, then the debug one can be renamed to and the burden put on the user to specify DYLD_IMAGE_SUFFIX to run their application with the debug library. If only the Debug configuration is installed, and it was still renamed, you'd have a broken framework. So, I don't know what you mean here. Can you be more specific, keeping in mind I don't know xcode? The behavior is basically the same as visual studio, if you know that, with the addition of this framework concept. While the whole build system supports multiple configurations, the user is only in one configuration at a given time. In contrast, building Qt can be done with makefiles that compile multiple configurations at the same time, but in practice, that kind of setup seems rare. Assuming there is some unavoidable reason that the configuration is not known when installing, does that mean that frameworks which contain a foo and a foo_debug can not be created by cmake? Yeah, that would seem to be the case. Unless someone has done it and can tell us how. Again, I wouldn't mind having a foo.framework/foo and foo-d.framework/foo-d which avoids this whole problem. I left a comment on the original Qt bug above that he should look into using DYLD_IMAGE_SUFFIX. Is that right? That is the correct response in the context of Qt. Clint -- 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] Building multiple configurations with Xcode?
- Original Message - - Original Message - clin...@elemtech.com wrote: - Original Message - Stephen Kelly wrote: Is it possible to build multi-config frameworks with cmake at all? I also notice that the Framework unit test uses set_target_properties(foo PROPERTIES FRAMEWORK TRUE DEBUG_POSTFIX -d ) but the debug file is called 'foo', not 'foo-d'. If I use cmake --build . --target install --config Debug cmake --build . --target install --config Release the debug and release versions overwrite each other. Does this mean it has always been broken? Has no one ever tried to create a framework using cmake? In the build tree, I would expect foo not foo-d for the debug framework. And in the build tree, it is possible to differentiate the release from debug simply by having two foo.framework/foo. One will be in the Release folder and one in the Debug folder, and a Debug build will use the one from the Debug folder, while the release build will use the one from the Release folder. That indeed appears to be what happens. But, I personally don't see a problem with there being a foo.framework/foo and a foo-d.framework/foo-d. At install time, they would not overwrite each other and the export file would need to list both of them. For the install tree, I don't see how it is known which configurations will be installed. I'm not familiar with xcode, so I assumed that if you install it would install all configurations, or you would specify which you want to install. Xcode works in one configuration at a time. The install target is the same way, by installing only one configuration at a time. When I use the command line I use cmake --build . --target install --config Debug so it is specified. That one configuration was specified, yes. But it isn't known if the Release one will also be installed. If it is known they are both being installed, and one wanted them to both go into the same framework, then the debug one can be renamed to and the burden put on the user to specify DYLD_IMAGE_SUFFIX to run their application with the debug library. If only the Debug configuration is installed, and it was still renamed, you'd have a broken framework. So, I don't know what you mean here. Can you be more specific, keeping in mind I don't know xcode? The behavior is basically the same as visual studio, if you know that, with the addition of this framework concept. While the whole build system supports multiple configurations, the user is only in one configuration at a given time. In contrast, building Qt can be done with makefiles that compile multiple configurations at the same time, but in practice, that kind of setup seems rare. Assuming there is some unavoidable reason that the configuration is not known when installing, does that mean that frameworks which contain a foo and a foo_debug can not be created by cmake? Yeah, that would seem to be the case. Unless someone has done it and can tell us how. Again, I wouldn't mind having a foo.framework/foo and foo-d.framework/foo-d which avoids this whole problem. Actually, I just realized a foo-d.framework/foo-d introduces another problem. In the code, you'd have to do a #include foo-d/foo.h for a debug build and a #include foo/foo.h for a release build, which I wouldn't want. Clint -- 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] Building multiple configurations with Xcode?
clin...@elemtech.com wrote: - Original Message - clin...@elemtech.com wrote: - Original Message - Stephen Kelly wrote: Is it possible to build multi-config frameworks with cmake at all? I also notice that the Framework unit test uses set_target_properties(foo PROPERTIES FRAMEWORK TRUE DEBUG_POSTFIX -d ) but the debug file is called 'foo', not 'foo-d'. If I use cmake --build . --target install --config Debug cmake --build . --target install --config Release the debug and release versions overwrite each other. Does this mean it has always been broken? Has no one ever tried to create a framework using cmake? In the build tree, I would expect foo not foo-d for the debug framework. And in the build tree, it is possible to differentiate the release from debug simply by having two foo.framework/foo. One will be in the Release folder and one in the Debug folder, and a Debug build will use the one from the Debug folder, while the release build will use the one from the Release folder. That indeed appears to be what happens. But, I personally don't see a problem with there being a foo.framework/foo and a foo-d.framework/foo-d. At install time, they would not overwrite each other and the export file would need to list both of them. Or Release/foo.framework/foo Debug/foo.framework/foo-d for a presumably smaller change. I don't know about export(), but install(EXPORT) is already fine. It installs multiple targets-config.cmake files, where each one would reference the correct IMPORTED_LOCATION_CONFIG. I just assumed that was already implemented. You might be able to tell me if there's some other location/file in a framework that would break though? (update: I think I understood below) For the install tree, I don't see how it is known which configurations will be installed. I'm not familiar with xcode, so I assumed that if you install it would install all configurations, or you would specify which you want to install. Xcode works in one configuration at a time. The install target is the same way, by installing only one configuration at a time. Ok, so you specify the configuration you want *this time? Then the configuration is known, right? We don't need to know all configurations that will be installed because of the multiple targets files. When I use the command line I use cmake --build . --target install --config Debug so it is specified. That one configuration was specified, yes. But it isn't known if the Release one will also be installed. If it is known they are both being installed, and one wanted them to both go into the same framework, then the debug one can be renamed to and the burden put on the user to specify DYLD_IMAGE_SUFFIX to run their application with the debug library. renamed to foo_debug ? I don't know for certain, but it seems that that is the common way of creating these things, right? If only the Debug configuration is installed, and it was still renamed, you'd have a broken framework. Ah, I think I understand now. If I install both debug and release, then I get foo.framework/foo foo.framework/foo_debug but if I install only the debug version, then I get only foo.framework/foo_debug And, you're saying that the framework system is not smart enough to work with that because the non-_debug version is missing? It doesn't just append the DYLD_IMAGE_SUFFIX on the name of the framework, and after locating the framework use that as the name of the file? So, I don't know what you mean here. Can you be more specific, keeping in mind I don't know xcode? The behavior is basically the same as visual studio, if you know that, I'm afraid I never used it extensively or for c++. with the addition of this framework concept. While the whole build system supports multiple configurations, the user is only in one configuration at a given time. ... and the user can only install/create their own frameworks as one configuration at a time? The user can't easily create/install multi-config frameworks? I left a comment on the original Qt bug above that he should look into using DYLD_IMAGE_SUFFIX. Is that right? That is the correct response in the context of Qt. Thanks! Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake --build . and colors
Hello, I am wondering if there is any trick to enable colors when running this command: cmake --build . The only way I manage to get the colors is to directly use the make program, e.g.: mingw32-make all The issue is that I am trying to use a script that runs cmake to build instead of the make program that may change (ninja, mingw-make, make, msvc, etc). Regards, Gregoire -- 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] Building multiple configurations with Xcode?
- Original Message - clin...@elemtech.com wrote: - Original Message - clin...@elemtech.com wrote: - Original Message - Stephen Kelly wrote: Is it possible to build multi-config frameworks with cmake at all? I also notice that the Framework unit test uses set_target_properties(foo PROPERTIES FRAMEWORK TRUE DEBUG_POSTFIX -d ) but the debug file is called 'foo', not 'foo-d'. If I use cmake --build . --target install --config Debug cmake --build . --target install --config Release the debug and release versions overwrite each other. Does this mean it has always been broken? Has no one ever tried to create a framework using cmake? In the build tree, I would expect foo not foo-d for the debug framework. And in the build tree, it is possible to differentiate the release from debug simply by having two foo.framework/foo. One will be in the Release folder and one in the Debug folder, and a Debug build will use the one from the Debug folder, while the release build will use the one from the Release folder. That indeed appears to be what happens. But, I personally don't see a problem with there being a foo.framework/foo and a foo-d.framework/foo-d. At install time, they would not overwrite each other and the export file would need to list both of them. Or Release/foo.framework/foo Debug/foo.framework/foo-d Ok, but the framework version of the linker flags -L,-l are used like this: -F/path/to/framework -framework foo which result in the linker would look for this file /path/to/framework/foo.framework/foo So, Debug/foo.framework/foo-d is not a valid framework. for a presumably smaller change. I don't know about export(), but install(EXPORT) is already fine. It installs multiple targets-config.cmake files, where each one would reference the correct IMPORTED_LOCATION_CONFIG. I just assumed that was already implemented. You might be able to tell me if there's some other location/file in a framework that would break though? (update: I think I understood below) See the case above. For the install tree, I don't see how it is known which configurations will be installed. I'm not familiar with xcode, so I assumed that if you install it would install all configurations, or you would specify which you want to install. Xcode works in one configuration at a time. The install target is the same way, by installing only one configuration at a time. Ok, so you specify the configuration you want *this time? Then the configuration is known, right? We don't need to know all configurations that will be installed because of the multiple targets files. When I use the command line I use cmake --build . --target install --config Debug so it is specified. That one configuration was specified, yes. But it isn't known if the Release one will also be installed. If it is known they are both being installed, and one wanted them to both go into the same framework, then the debug one can be renamed to and the burden put on the user to specify DYLD_IMAGE_SUFFIX to run their application with the debug library. renamed to foo_debug ? I don't know for certain, but it seems that that is the common way of creating these things, right? If only the Debug configuration is installed, and it was still renamed, you'd have a broken framework. Ah, I think I understand now. If I install both debug and release, then I get foo.framework/foo foo.framework/foo_debug but if I install only the debug version, then I get only foo.framework/foo_debug And, you're saying that the framework system is not smart enough to work with that because the non-_debug version is missing? It doesn't just append the DYLD_IMAGE_SUFFIX on the name of the framework, and after locating the framework use that as the name of the file? With the -F/-framework link flags, the linker looks for foo.framework/foo The DYLD_* variables are used by the dynamic loader at runtime and do not affect the linker. So, I don't know what you mean here. Can you be more specific, keeping in mind I don't know xcode? The behavior is basically the same as visual studio, if you know that, I'm afraid I never used it extensively or for c++. with the addition of this framework concept. While the whole build system supports multiple configurations, the user is only in one configuration at a given time. ... and the user can only install/create their own frameworks as one configuration at a time? The user can't easily create/install multi-config frameworks? Yes. Its a separate step to handle multiple configurations, like you did earlier. cmake --build . --target install --config Debug cmake --build . --target install --config Release And yes, with frameworks, there is the issue of overwriting
Re: [CMake] Building multiple configurations with Xcode?
clin...@elemtech.com wrote: Or Release/foo.framework/foo Debug/foo.framework/foo-d Ok, but the framework version of the linker flags -L,-l are used like this: -F/path/to/framework -framework foo which result in the linker would look for this file /path/to/framework/foo.framework/foo So, Debug/foo.framework/foo-d is not a valid framework. CMake seems to already be putting the framework in a Debug/Release folder. Does that mean that they are not valid frameworks in the build dir? Does that mean they can't be used from the build dir at all? What if you use -F/path/to/framework/Debug ? For the install tree, I don't see how it is known which configurations will be installed. I'm not familiar with xcode, so I assumed that if you install it would install all configurations, or you would specify which you want to install. Xcode works in one configuration at a time. The install target is the same way, by installing only one configuration at a time. Ok, so you specify the configuration you want *this time? Then the configuration is known, right? We don't need to know all configurations that will be installed because of the multiple targets files. When I use the command line I use cmake --build . --target install --config Debug so it is specified. That one configuration was specified, yes. But it isn't known if the Release one will also be installed. If it is known they are both being installed, and one wanted them to both go into the same framework, then the debug one can be renamed to and the burden put on the user to specify DYLD_IMAGE_SUFFIX to run their application with the debug library. renamed to foo_debug ? I don't know for certain, but it seems that that is the common way of creating these things, right? If only the Debug configuration is installed, and it was still renamed, you'd have a broken framework. Ah, I think I understand now. If I install both debug and release, then I get foo.framework/foo foo.framework/foo_debug but if I install only the debug version, then I get only foo.framework/foo_debug And, you're saying that the framework system is not smart enough to work with that because the non-_debug version is missing? It doesn't just append the DYLD_IMAGE_SUFFIX on the name of the framework, and after locating the framework use that as the name of the file? With the -F/-framework link flags, the linker looks for foo.framework/foo The DYLD_* variables are used by the dynamic loader at runtime and do not affect the linker. I see. I wonder if this leaves us in a solvable situation. ... and the user can only install/create their own frameworks as one configuration at a time? The user can't easily create/install multi-config frameworks? Yes. Its a separate step to handle multiple configurations, like you did earlier. cmake --build . --target install --config Debug cmake --build . --target install --config Release And yes, with frameworks, there is the issue of overwriting files. I don't really care about this problem, yet. Only on windows is a debug library required for regular development because of the configuration specific C/C++ runtime libraries. If I made a framework for other people to use, and if for some reason they wanted to debug my framework, they could simply compile a debug only version and link with that. So I don't see a big need for both a release and debug framework. Closed source is not common/relevant? In the past, when I've had to debug the Qt libraries on Mac, I've either made a debug only build, or modified the frameworks. The modification was because Qt uses the same _debug suffix as the whole system, and I don't want the debug version of all of the system libraries because it is way too slow. So anyway, for me, this is a very low priority problem compared to other cmake issues. Right. The reporter at https://bugreports.qt-project.org/browse/QTBUG-30938 raises a reason that DYLD_IMAGE_SUFFIX doesn't work for him anyway. I wonder what qmake does here. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building multiple configurations with Xcode?
On Friday, May 03, 2013 05:48:20 PM Stephen Kelly wrote: clin...@elemtech.com wrote: Or Release/foo.framework/foo Debug/foo.framework/foo-d Ok, but the framework version of the linker flags -L,-l are used like this: -F/path/to/framework -framework foo which result in the linker would look for this file /path/to/framework/foo.framework/foo So, Debug/foo.framework/foo-d is not a valid framework. CMake seems to already be putting the framework in a Debug/Release folder. Does that mean that they are not valid frameworks in the build dir? Does that mean they can't be used from the build dir at all? What if you use -F/path/to/framework/Debug ? Actually Release/foo.framework/foo Debug/foo.framework/foo are valid frameworks. You can use -F/path/to/framework/Debug for a debug build and -F/path/to/framework/Release for a release build. That's basically identical to have a release-only Qt installed in one place, and a debug-only Qt installed in another place. Or even a single configuration build tree in one place, and another build tree in another place. So, CMake doesn't have issues in the build tree. It only a problem in the install tree when trying to put multiple configurations in the same tree. For the install tree, I don't see how it is known which configurations will be installed. I'm not familiar with xcode, so I assumed that if you install it would install all configurations, or you would specify which you want to install. Xcode works in one configuration at a time. The install target is the same way, by installing only one configuration at a time. Ok, so you specify the configuration you want *this time? Then the configuration is known, right? We don't need to know all configurations that will be installed because of the multiple targets files. When I use the command line I use cmake --build . --target install --config Debug so it is specified. That one configuration was specified, yes. But it isn't known if the Release one will also be installed. If it is known they are both being installed, and one wanted them to both go into the same framework, then the debug one can be renamed to and the burden put on the user to specify DYLD_IMAGE_SUFFIX to run their application with the debug library. renamed to foo_debug ? I don't know for certain, but it seems that that is the common way of creating these things, right? If only the Debug configuration is installed, and it was still renamed, you'd have a broken framework. Ah, I think I understand now. If I install both debug and release, then I get foo.framework/foo foo.framework/foo_debug but if I install only the debug version, then I get only foo.framework/foo_debug And, you're saying that the framework system is not smart enough to work with that because the non-_debug version is missing? It doesn't just append the DYLD_IMAGE_SUFFIX on the name of the framework, and after locating the framework use that as the name of the file? With the -F/-framework link flags, the linker looks for foo.framework/foo The DYLD_* variables are used by the dynamic loader at runtime and do not affect the linker. I see. I wonder if this leaves us in a solvable situation. ... and the user can only install/create their own frameworks as one configuration at a time? The user can't easily create/install multi-config frameworks? Yes. Its a separate step to handle multiple configurations, like you did earlier. cmake --build . --target install --config Debug cmake --build . --target install --config Release And yes, with frameworks, there is the issue of overwriting files. I don't really care about this problem, yet. Only on windows is a debug library required for regular development because of the configuration specific C/C++ runtime libraries. If I made a framework for other people to use, and if for some reason they wanted to debug my framework, they could simply compile a debug only version and link with that. So I don't see a big need for both a release and debug framework. Closed source is not common/relevant? For closed source, they could gather some meaningful information with a debug framework. Having a foo.framework/Versions/A/foo foo.framework/Versions/A/foo_debug would be a quick way for them to debug by setting DYLD_IMAGE_SUFFIX=_debug. That's certainly quicker than recompiling their app against a debug framework in a different location. But, if I chose to give them this: Release/foo.framework/Versions/A/foo Debug/foo.framework/Versions/A/foo and their debug build was already linked with the debug foo framework, then debugging can already be done without setting any environment variable to tell the dynamic loader to use a different library. There are a few options here. In the past, when I've had to
Re: [CMake] turning inverting dashboard interpretation of FATAL_ERRORs at cmake
On Thursday 25 April 2013 20:09:09 Alexander Neundorf wrote: On Thursday 25 April 2013, Matthias Kretz wrote: On Thursday 25 April 2013 09:46:03 Bill Hoffman wrote: On 4/25/2013 9:15 AM, Matthias Kretz wrote: I have several checks in my project that make cmake error out with FATAL_ERROR. This is submitted as error to the dashboard. In reality it would be an error if this error would not appear - and it is the expected result if cmake errors out. Is there a possiblity to invert the result of the configure step for certain system setups? Alternatively I'd skip the CTEST_CONFIGURE call in the ctest script and just submit Notes that elaborate on the abort. But that doesn't show up on the dashboard at all. Any ideas? Is this for an individual test? If so, you can use the regex matching instead of return code to determine pass fail. Would that work? I'm not sure we're talking about the same thing. I'm talking about ctest_configure - i.e. before build or tests. IIUC you're talking about regex matching at ctest_test? so the good result is if the configure step of your project fails ? Exactly. And running some cmake code in the test phase is certainly possible, but not what I'm looking for. It would require the configure step of my project to pass, disable all targets, and enable a test that doesn't do anything useful anymore, because the test already happened at configure time. So I could also simply skip that and just let configure pass + disable all targets. -- Matthias Kretz (Germany) http://kretzfamily.de/ -- 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 --build . and colors
Hello, I also found that using cmake --build . with ninja outputs all lines but if I directly use ninja to build it only outputs one line which is very cool (it clears current line before printing the new one if there is no warning/error). Regards, Gregoire From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Gregoire Aujay Sent: vendredi 3 mai 2013 16:39 To: cmake@cmake.org Subject: [CMake] cmake --build . and colors Hello, I am wondering if there is any trick to enable colors when running this command: cmake --build . The only way I manage to get the colors is to directly use the make program, e.g.: mingw32-make all The issue is that I am trying to use a script that runs cmake to build instead of the make program that may change (ninja, mingw-make, make, msvc, etc). Regards, Gregoire -- 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] include(InstallRequiredSystemLibraries) not working with NSIS
Hello, I'm kinda new. I've written a Qt program in Linux Mint, ported it over to windows with Mingw32, got building working with CMake in Linux and windows, and integrated CPack to create a .deb installer. The debian package has nice automatic package resolution, but I am having trouble getting the NSIS installer to grab the required libraries. I've searched the help and the closest email chain I could find was this: http://www.cmake.org/pipermail/cmake/2008-July/023076.html They seem to have solved the issue for them, but I have not been able to follow what they were doing well enough to get it to work (they didn't post the CMakeLists). I've very new with Windows development. If I may ask, is sticking the required .dlls in the same directory as the application sufficient for it to find them? My build file below makes a functional installer, but despite using include(InstallRequiredSystemLibraries) only the binary is copied. If I may ask, what do I need to do to get the required .dlls to copy into the installer? I'm using windows terminal with qt5's built in mingw32 compiler. CMakeLists.txt http://cmake.3232098.n2.nabble.com/file/n7584348/CMakeLists.txt Commands to compile: cmake -GMinGW Makefiles mingw32-make.exe package -- View this message in context: http://cmake.3232098.n2.nabble.com/include-InstallRequiredSystemLibraries-not-working-with-NSIS-tp7584348.html Sent from the CMake mailing list archive at Nabble.com. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] undefined reference to symbol 'keypad'
Dear All, I am trying to compile cmake 2.8.10 on a computer with the following operating system: /opt/centos/devtoolset-1.1/root/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/ld: note: 'keypad' is defined in DSO /lib64/libtinfo.so.5 so try adding it to the linker command line /lib64/libtinfo.so.5: could not read symbols: Invalid operation Could you please advice if you know the problem? Thank you -- Matteo -- 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 determine the compiler used outside of cmake
Instead of overriding the compiler in the CMakeLists.txt to a specific compiler version, why not guide CMake's compiler detection from the outside and have CMake choose the one you want? For instance, since you're already using a wrapper to drive the CMAKe build, you could call cmake with cmake -DCMAKE_C_COMPILER=/usr/bin/gcc44 -DCMAKE_CXX_COMPILER=/usr/bin/g++44 ... or inside your wrapper script, you could export the CC and CXX environment variables. This will allow your CMake build to be clean and portable while abstracting the configuration specific to your particular environment to the wrapper script you're already using. You could also look at using pre-defined cache files to prime a collection of commonly used settings. Using a pre-defined cache file has actually turned out to be a good solution for my group here when we had to maintain a hand-full of commonly used build configurations. The cache files just look like: --- set(OPTION1 ON CACHE BOOL Doc for Option 1) set(OPTION2 /path/to/foo CACHE FILEPATH Doc for Option 2) set(CMAKE_CXX_COMPILER /usr/bin/g++44 CACHE FILEPATH CXX Compiler) ... --- And then you can instruct CMake to pre-load it's cache values via: cmake -C /path/to/settings.cmake /path/to/source A common use case for us is to have a particular set of options that are set specifically for RHEL5 and another set when building for RHEL6. It's then often convenient to keep these in the repo with the rest of the code. Just a though - Chuck On Thu, May 2, 2013 at 3:35 PM, Miller, Frank fmil...@sjm.com wrote: Update. The reason I didn’t have CMAKE_CXX_COMPILER in my cache is because I was doing a ** ** set(CMAKE_CXX_COMPILER /usr/bin/g++44 ) ** ** at the top of my root CMakeLists.txt. That preempts the set( CACHE ) call that project() does. My bad. ** ** Frank ** ** *From:* cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] *On Behalf Of *Miller, Frank *Sent:* Thursday, May 02, 2013 9:51 AM *To:* m.hergar...@euphoria-it.nl *Cc:* cmake@cmake.org *Subject:* Re: [CMake] How to determine the compiler used outside of cmake ** ** Interesting. I am running a very recent version (2.8.10.20130415) built from git. Perhaps the handling of CMAKE_CXX_COMPILER has changed recently. ** ** I can’t believe I didn’t think to manually put it in the cache. That will work for me. Thanks. ** ** As for the bigger problem I am solving... I have a wrapper script that drives the build. This is done to emulate a legacy build system and add some nice-to-haves. For example, the user can call the script from their source tree and it will call cmake/ninja in the proper binary tree. The default compiler to be used is hard coded into the CMakeLists.txt and I would like to have the script detect when the compiler changes and do a reconfigure automatically. ** ** Now that I’m explaining the larger problem, I think I will have to put extra information in the cache to detect when the user manually overrides the default compiler. So I probably would have come around to your suggestion on my own. ** ** Thanks again, ** ** Frank ** ** *From:* m.hergarden [mailto:m.hergar...@euphoria-it.nlm.hergar...@euphoria-it.nl] *Sent:* Thursday, May 02, 2013 12:16 AM *To:* Miller, Frank *Cc:* cmake@cmake.org *Subject:* Re: [CMake] How to determine the compiler used outside of cmake ** ** The compiler does show up in my cache: CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++, but that doesn't solve your issue. What is the bigger problem you are solving? If you really really need it in the cache, you can always write a variable yourself to make sure it's there. Regards, Micha On 05/01/2013 09:56 PM, Miller, Frank wrote: Greetings, Given a configured build tree, I would like to determine the c++ compiler used without reconfiguring. I expected the CMAKE_CXX_COMPILER variable would be in the CMakeCache.txt but I was wrong. I tried to run a simple cmake script with ‘cmake -P’ and print the value of CMAKE_CXX_COMPILER but that does not work. I found the value in ‘CMakeFiles/2.8.10.20130415/CMakeCXXCompiler.cmake’, so I have a workaround, but that smells like the wrong solution. Does anyone know of a better way? Thanks as always, Frank This communication, including any attachments, may contain information that is proprietary, privileged, confidential or legally exempt from disclosure. If you are not a named addressee, you are hereby notified that you are not authorized to read, print, retain a copy of or disseminate any portion of this communication without the consent of the sender and that doing so may be unlawful. If you have received this communication in error, please immediately notify the sender via return e-mail and delete it from your system. -- ** ** Powered by www.kitware.com ** **
[Cmake-commits] CMake branch, master, updated. v2.8.10.2-1014-g21bdead
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 21bdeadf00eb66d1e6c14b99ef0b67432d6fe31b (commit) from 41839d6fb690225c5779b02d113d0d38ee77d9ba (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=21bdeadf00eb66d1e6c14b99ef0b67432d6fe31b commit 21bdeadf00eb66d1e6c14b99ef0b67432d6fe31b Author: Kitware Robot kwro...@kitware.com AuthorDate: Sat May 4 00:01:02 2013 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Sat May 4 00:01:02 2013 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index e653c4a..03e3bb2 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 10) -set(CMake_VERSION_TWEAK 20130503) +set(CMake_VERSION_TWEAK 20130504) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.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
