[CMake] How to detect whether CMake scripts are executing under / within CPack environment?

[Mike McQuaid]

On 20 December 2010 16:07, Clinton Stimpson <clinton at 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