[CMake] ExternalProject + PREFIX + CPACK - cannot get the good path

[Eric Noulard]

2017-07-17 22:54 GMT+02:00 Alfred Sawaya <alfred at huji.fr>:

> Hello folks,
>
> I am trying to create a package with CPack from an External Project using
> the autotools. The make install part try to copy files to /usr/local/lib,
> but I do not want to package as root, so it fails. The cpack works because
> (I think) it create a temp dir and set it as environment variable before
> issuing the make install.
>

Yes it does, in fact some CPack generator automatically set the DESTDIR var
in order to tolerate files installed with absolute path.
This is the case (at least) of RPM and DEB generator.

In fact in your case if you try e.g. ZIP generator with

cpack -G ZIP

it will fail as with "make package".



> But if I do a "make package", then it fails with permissions denied.
>

Yep.
Because the pre-install target required by cpack does not use DESTDIR
mechanism and thus uses the default prefix from /configure which is
probably /usr/local

Note that the very simple "make" which tries to BUILD and INSTALL the
external project fails as well because it wants to install is /usr/local.

e.g. note that with your current setup if you do:
DESTDIR=/tmp make package

you get what you want in the DEB file.


>
> I am not the first to get stuck with this issue (
> https://stackoverflow.com/questions/44724281/cpack-
> building-external-autogen-project-with-bad-output-location)
> So I do not think that there is a direct solution ? Anyway, I can
> implement one and send the patch.
>
> I see only one solution to this issue: actually set a prefix on the
> external project and implement a boolean variable
> CPACK_IGNORE_INSTALL_PREFIX to remove it into the package. I tihnk it is
> the most consistent way to resolve this ?
>

I would say you should find a way to have 2 differents prefixes.

The first should be used when doing "make"
The second one used when cpack runs.

All that said, may be you can "simply" craft an install_command script you
can call in the
INSTALL_COMMAND argument of ExternalProject_Add and which verifies if
DESTDIR is already set or not
in order to call "make install" or "DESTDIR=/choose/your/path make install".

However this is kind of workaround to throw away the first install step
done when doing make while
keeping the second one done by cpack...

Which makes me think, if you primary goal is to package an external
project, wouldn't it be simpler to add support for a "PACKAGE" step to
ExternalProject ? Or is this external project meant to be packaged in the
same package as the project using it?


--
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170718/de18e380/attachment-0001.html>