Re: [CMake] How to detect whether CMake scripts are executing under / within CPack environment?
On Sun, Dec 19, 2010 at 3:50 PM, Mike McQuaid m...@mikemcquaid.com wrote:
On 16 December 2010 08:34, Andreas Mohr a...@lisas.de wrote:
I'd like to know how to possibly detect this within CMake code.
This works for me:
INSTALL( CODE
IF( \${CMAKE_INSTALL_PREFIX} MATCHES .*/_CPack_Packages/.* )
ENDIF( \${CMAKE_INSTALL_PREFIX} MATCHES .*/_CPack_Packages/.* )
)
However, you then need to put all your CMake logic in INSTALL(CODE
...) logic. Either later tonight or tomorrow I'll post my suggestions
to this list for possible patches I will try and get included to
improve this situation as INSTALL(CODE ...) escaping isn't trivial.
--
Mike McQuaid
http://mikemcquaid.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
When you find yourself in the must escape too much situation in an
INSTALL(CODE scenario you should switch to writing out a script that you
then include with an INSTALL(SCRIPT command. They are absolutely equivalent,
except with CODE you specify the code inline when it does not need
significant escaping, or if it's just a line or two. If it does need lots of
escaping or is longer than 1-3 lines, I would say it should be the SCRIPT
form anyway.
And honestly, I think that Eric's suggestion of using a
CPACK_PROJECT_CONFIG_FILE is the way to go here. If you have one, CPack will
include it before running your install rules. You can use any sentinel you
like within that file: it will only ever be included by CPack, so if you're
in its context, then you know you're being run by CPack.
HTH,
David
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to detect whether CMake scripts are executing under / within CPack environment?
On 20 December 2010 12:34, David Cole david.c...@kitware.com wrote: On Sun, Dec 19, 2010 at 3:50 PM, Mike McQuaid m...@mikemcquaid.com wrote: When you find yourself in the must escape too much situation in an INSTALL(CODE scenario you should switch to writing out a script that you then include with an INSTALL(SCRIPT command. They are absolutely equivalent, except with CODE you specify the code inline when it does not need significant escaping, or if it's just a line or two. If it does need lots of escaping or is longer than 1-3 lines, I would say it should be the SCRIPT form anyway. And honestly, I think that Eric's suggestion of using a CPACK_PROJECT_CONFIG_FILE is the way to go here. If you have one, CPack will include it before running your install rules. You can use any sentinel you like within that file: it will only ever be included by CPack, so if you're in its context, then you know you're being run by CPack. That's a good suggestion and could do with being better documented (like most of CPack)! I still think the nicest solution would be to provide INSTALL(... PACKAGE) or something similar so you can do this all easily and visibly from your existing CMakeLists.txt files. That's my main reservation with using too many external script files, it's not obvious to someone reading the CMakeLists file what is actually happening. I'm happy to write a patch for this. Would this be accepted? Is this the wrong approach? If you guide me to creating an acceptable one, I'd be happy to write this. I created a bug about this so this is probably a good point of discussion: http://public.kitware.com/Bug/view.php?id=11142 -- Mike McQuaid http://mikemcquaid.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to detect whether CMake scripts are executing under / within CPack environment?
On Mon, Dec 20, 2010 at 7:51 AM, Mike McQuaid m...@mikemcquaid.com wrote: On 20 December 2010 12:34, David Cole david.c...@kitware.com wrote: On Sun, Dec 19, 2010 at 3:50 PM, Mike McQuaid m...@mikemcquaid.com wrote: When you find yourself in the must escape too much situation in an INSTALL(CODE scenario you should switch to writing out a script that you then include with an INSTALL(SCRIPT command. They are absolutely equivalent, except with CODE you specify the code inline when it does not need significant escaping, or if it's just a line or two. If it does need lots of escaping or is longer than 1-3 lines, I would say it should be the SCRIPT form anyway. And honestly, I think that Eric's suggestion of using a CPACK_PROJECT_CONFIG_FILE is the way to go here. If you have one, CPack will include it before running your install rules. You can use any sentinel you like within that file: it will only ever be included by CPack, so if you're in its context, then you know you're being run by CPack. That's a good suggestion and could do with being better documented (like most of CPack)! I still think the nicest solution would be to provide INSTALL(... PACKAGE) or something similar so you can do this all easily and visibly from your existing CMakeLists.txt files. That's my main reservation with using too many external script files, it's not obvious to someone reading the CMakeLists file what is actually happening. I'm happy to write a patch for this. Would this be accepted? Is this the wrong approach? If you guide me to creating an acceptable one, I'd be happy to write this. I created a bug about this so this is probably a good point of discussion: http://public.kitware.com/Bug/view.php?id=11142 -- Mike McQuaid http://mikemcquaid.com I don't think an INSTALL(... PACKAGE construct is necessary. And, in fact, I think it might be harmful. (For one thing, INSTALL(PACKAGE sounds like you're installing a package, not like you're installing something you've built but only as part of an installer package.) For the simple case, the binary package is nothing more than a copy of the make install tree. Adding stuff to the tree, but only for package installers, is unusual. But it is possible with existing mechanisms. (I still wouldn't recommend doing it.) Why do you have differences in one install tree vs. another? ___ 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 detect whether CMake scripts are executing under / within CPack environment?
On 20 December 2010 13:17, David Cole david.c...@kitware.com wrote: I don't think an INSTALL(... PACKAGE construct is necessary. And, in fact, I think it might be harmful. (For one thing, INSTALL(PACKAGE sounds like you're installing a package, not like you're installing something you've built but only as part of an installer package.) Ok. I'm not saying that's the best keyword or anything like that but just something that handles the escaping for you but lets you specify files within CMake. For the simple case, the binary package is nothing more than a copy of the make install tree. Adding stuff to the tree, but only for package installers, is unusual. But it is possible with existing mechanisms. (I still wouldn't recommend doing it.) Why do you have differences in one install tree vs. another? Anyone who uses GetPrerequisites or BundleUtilities will do. I've had this problem now on 5+ projects between 2+ employers. You will want to install the libraries for your application to a package you can distribute but not to people on e.g. Linux who just want to type make install and had it use their system libraries. Another case is adding things like the README which should be in the root of the zip/dmg package but in $PREFIX/share/doc for installations. Also, you might want to fix up RPATHS for installed versions but not local ones. You'll also need to supply a qt.conf file for Qt installations at package-time but not install-time. Any open-source project where you want to provide binary package support using CMake but allow people to create normal Linux/Mac packages themselves (e.g. Debian) will require a different install/package tree. In my experience, literally every time I've used CPack for a project or recommended it to others they've required this functionality. That's not to say that it is used in every single project using CPack out there but it seems to be necessary to a lot of users. -- Mike McQuaid http://mikemcquaid.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to detect whether CMake scripts are executing under / within CPack environment?
On 20 December 2010 16:07, Clinton Stimpson clin...@elemtech.com wrote: BundleUtilities already skips system libraries, so I don't see a difference between making a package and make install in this case. If you're using all system libraries, BundleUtilities can become a no-op. You're basically saying don't use BundleUtilities and CPack to create binary packages for open-source projects. On Mac or Windows I want to be able to distribute to users using both package managers and binary packages (e.g. CPack installers). The prior handles dependencies for you so you don't want to install anything not built by the project. The latter requires you to bundle all dependencies not distributed with a default install of the system. I don't mind if BundleUtilities is run or not, just that the libraries aren't installed with make install and are installed with make package. Another case is adding things like the README which should be in the root of the zip/dmg package but in $PREFIX/share/doc for installations. Then you'll have to differentiate between cpack generators. You might want that for zip and dmg, but not for rpm and deb. Yes, you might. Also, you might just not use those generators. Why would this matter? If you're using system libraries, rpaths are not needed and ld.so.conf does the work for you. When a package is made, you want absolute rpaths removed anyway, since they may not work on other systems. It might not matter to you, it's just another example of concerns people have in the open-source world. You'll also need to supply a qt.conf file for Qt installations at package-time but not install-time. I think, whether to make qt.conf and add Qt plugins is really dependent on whether the Qt libraries will get copied by BundleUtilities, not whether you're doing a make install vs. a make package. Qt plugins won't be installed by BundleUtilities as far as I can see. In this case, you're somewhat mixing together BundleUtilities and CPack. I've never seen any use for BundleUtilities on any of the projects I've worked on either commercially or in open-source work for anything other than generating packages that are distributed to users. This is packaging as far as I can see, not installation. Any open-source project where you want to provide binary package support using CMake but allow people to create normal Linux/Mac packages themselves (e.g. Debian) will require a different install/package tree. In my experience, literally every time I've used CPack for a project or recommended it to others they've required this functionality. That's not to say that it is used in every single project using CPack out there but it seems to be necessary to a lot of users. BundleUtilities still works in this case but can basically become a no-op. I don't mind whether BundleUtilities works or not. This discussion is about CPack and CMake's interaction, not really about BundleUtilities. I'm trying really hard to be an advocate of CPack, I've done internal company presentations at several companies, I plug it when I do Qt trainings and did a talk and workshop at the KDE conference before last at it. At my current company (KDAB) we're trying to use CPack for several internal products and an open-source tool. Personally, I'm trying to use it for some open-source projects and producing decent Mac KDE binary packages. This is a problem that I keep running into again and again and currently there isn't a nice solution. When I show people INSTALL(CODE) blocks or external scripts required for the above, they go oh and I can see their desire to use CPack decreases. I'm happy to try and fix this but please don't tell me this isn't a problem. -- Mike McQuaid http://mikemcquaid.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to detect whether CMake scripts are executing under / within CPack environment?
On 16 December 2010 08:34, Andreas Mohr a...@lisas.de wrote:
I'd like to know how to possibly detect this within CMake code.
This works for me:
INSTALL( CODE
IF( \${CMAKE_INSTALL_PREFIX} MATCHES .*/_CPack_Packages/.* )
ENDIF( \${CMAKE_INSTALL_PREFIX} MATCHES .*/_CPack_Packages/.* )
)
However, you then need to put all your CMake logic in INSTALL(CODE
...) logic. Either later tonight or tomorrow I'll post my suggestions
to this list for possible patches I will try and get included to
improve this situation as INSTALL(CODE ...) escaping isn't trivial.
--
Mike McQuaid
http://mikemcquaid.com
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to detect whether CMake scripts are executing under / within CPack environment?
2010/12/16 Andreas Mohr a...@lisas.de: Hi, [subject formulated for best keyword search impact] forgive me for the possibly dumb question, but since cpack of course includes executing the make install step I'd like to know how to possibly detect this within CMake code. My build is capable of launching an external script to pop up a build complete message, which then of course unhelpfully also occurs during cpack -G DEB (thus completely stopping the packaging due to non-parallel build execution in this environment), thus it would be useful to automatically turn it off in such cases. Of course a potential solution might actually turn out to be generator-specific (e.g. Makefile). :-P I'm afraid since CPack is likely executing a generated CMake environment, detection is difficult or even impossible. This is an interesting question. Currently I think you are right there is no *builtin* way to know if your script is being run from within CPack. I think the feature is interesting and it is worth a feature request. The solution is easy: make CPack defines something like CPACK_IS_RUNNING variable and then you can do IF(CPACK_IS_RUNNING) from within your script. Builtin support for this needs [very small] patch. Now you can emulate this feature by using a CPACK_PROJECT_CONFIG_FILE. See the doc here: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29 The CPACK_PROJECT_CONFIG_FILE is loaded by CPack for each generator it has to launch so if you unconditionnally define set(CPACK_IS_RUNNING 1) in this file then CPACK_IS_RUNNING will be defined before your install time script is runned. I didn't tried but I think it should work as expected. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
