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

[Clinton Stimpson]

On Monday, December 20, 2010 06:35:31 am Mike McQuaid wrote:
> On 20 December 2010 13:17, David Cole <david.cole at 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.

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.

> 
> 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.

> Also, you might want to fix up RPATHS for installed
> versions but not local ones. 

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.

> 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.

> 
> 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.

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com