ExternalProject + PREFIX + CPACK - cannot get the good path

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ExternalProject + PREFIX + CPACK - cannot get the good path

Alfred Sawaya
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. But if I do a "make package", then it fails with permissions denied.

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 ?
Do you have other ideas before I start implementing it ? 

Thank you all,
Alfred

The CMakeLists.txt: (usable as is) <<<EOF

project(sqlcipher)

cmake_minimum_required (VERSION 2.8)

include(ExternalProject)

ExternalProject_Add(
    sqlcipher
    BUILD_IN_SOURCE true
    CONFIGURE_COMMAND ./configure --enable-tempstore=yes "CFLAGS=-DSQLITE_HAS_CODEC"
)


set(CPACK_DEBIAN_PACKAGE_PROVIDES libsqlcipher0 libsqlcipher-dev sqlcipher)
set(CPACK_DEBIAN_PACKAGE_REPLACES ${CPACK_DEBIAN_PACKAGE_PROVIDES})
set(CPACK_DEBIAN_PACKAGE_CONFLICTS ${CPACK_DEBIAN_PACKAGE_PROVIDES})

SET(CPACK_GENERATOR "DEB")
SET(CPACK_PACKAGE_NAME "my-sqlcipher")
SET(CPACK_PACKAGE_VERSION "3.15")

SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "me")
SET(CPACK_DEBIAN_PACKAGE_DESCRIPTION "Install the last version of sqlcipher")

SET(CPACK_DEBIAN_PACKAGE_ARCHITECTURE "all")
SET(CPACK_PACKAGE_FILE_NAME "${CPACK_PACKAGE_NAME}_${CPACK_PACKAGE_VERSION}_${CPACK_DEBIAN_PACKAGE_ARCHITECTURE}")
INCLUDE(CPack)

EOF

make package  # fails if not root
cpack # succes if not root

--
Cordialement,
Alfred Sawaya

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ExternalProject + PREFIX + CPACK - cannot get the good path

Eric Noulard


2017-07-17 22:54 GMT+02:00 Alfred Sawaya <[hidden email]>:
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.
 

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


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ExternalProject + PREFIX + CPACK - cannot get the good path

Alfred Sawaya
Bonjour Eric,

Thank you for you answer.



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

you get what you want in the DEB file.

Yes, it works.
 

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.

An option like "CMAKE_ONLY_PREFIX" in the ExternalProject ?

A third solution could be:
An option like "CPACK_OVERRIDE_DEST_DIR" could detect if 'DESTDIR=' is issued in the INSTALL_COMMAND of the external project. If the option is true, it overrides it with the CPACK_INSTALL_PREFIX.


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...
 
Actually it would work for me as I do not use the first make install. It is the same as DESTDIR=/tmp make package, but integrated into the CMakeLists.


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?
 
I cannot add a package step as the external project do not support packaging, it is only a configure / make / make install project. That is why I use CPack. 
But I package it as a separate package.


Anyway, the DESTDIR=/tmp make package does the trick for me but I still can implement an integrated solution if it is useful for others ?



--
Eric

--
Cordialement,
Alfred Sawaya

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ExternalProject + PREFIX + CPACK - cannot get the good path

Eric Noulard



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?
 
I cannot add a package step as the external project do not support packaging, it is only a configure / make / make install project. That is why I use CPack. 
But I package it as a separate package.

Yep I understand that. 
My suggestion was precisely to **add** a package step to ExternalProject unless it doesn't make sense for ExternalProject_Add

May be you can do that with ExternalProject_Add_Step in your own CMakeLists.txt ?

Something like (untested):

ExternalProject_Add_Step(sqlcipher package
    COMMAND "cpack"
    WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
    COMMENT "Package with cpack"
    DEPENDEES "install"
 )

I don't know much about ExternalProject internals so I may be wrong.

Anyway, the DESTDIR=/tmp make package does the trick for me but I still can implement an integrated solution if it is useful for others ?

As I said this trick is only a way to throw away (in /tmp) the default install command which is called by
make (or make package) as the part of the install step of ExternalProject_Add.

-- 
Eric

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ExternalProject + PREFIX + CPACK - cannot get the good path

Alfred Sawaya
May be you can do that with ExternalProject_Add_Step in your own CMakeLists.txt ?

Something like (untested):

ExternalProject_Add_Step(sqlcipher package
    COMMAND "cpack"
    WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
    COMMENT "Package with cpack"
    DEPENDEES "install"
 )

It does not work because the install step still tries to install files to /usr/local/lib and if I set INSTALL_COMMAND at "", CPack will produce an empty package. So I would still need to play with DESTDIR the same way as if I use include(CPack).
 

I don't know much about ExternalProject internals so I may be wrong.

Anyway, the DESTDIR=/tmp make package does the trick for me but I still can implement an integrated solution if it is useful for others ?

As I said this trick is only a way to throw away (in /tmp) the default install command which is called by
make (or make package) as the part of the install step of ExternalProject_Add.

-- 
Eric
--
Cordialement,
Alfred Sawaya

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Loading...