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
