Fwd: Using CPack to package things not built using CMake

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Using CPack to package things not built using CMake

Bruce Stephens
Sorry, that should obviously have gone to this mailing list.

---------- Forwarded message ----------
From: Bruce Stephens <[hidden email]>
Date: Mon, May 23, 2016 at 2:40 PM
Subject: Using CPack to package things not built using CMake
To: [hidden email]


Suppose I have a build which uses a number of external projects
(perhaps built using ExternalProject_Add) but which use a variety of
build systems.

And I want to package the result (so I arrange for the external
projects to build expecting themselves to be installed under
/opt/foo).

What are good ways to do that, without going in and replacing all the
existing build systems with CMake (which is likely the route we'll
take for some, but doing all doesn't seem practical)?

A possibility is just to build static rather than shared libraries;
for quite a few cases that would mean nothing would need to be
installed.

Another one (which would be a bit more general, I think) is to replace
the build with a CMake wrapper, so the building bit calls the
underlying build script but the install part is all done in CMake. In
these cases the numbers of files is usually quite small, so doing that
shouldn't be too annoying, and would presumably produce the right
scripts to use in CPack.

Any better ideas (or problems I'm missing with the last idea I suggest)?
--

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
|

Re: Fwd: Using CPack to package things not built using CMake

Chuck Atkins
Hi Bruce,

CPack basically packages up everything that gets "installed".  We've got a number of superbuilds as we call them that work this way.  Basically you have all of your external projects perform their install into the same temporary location somewhere in the build tree, like ${project_name_BINARY_DIR}/install_staging.  Then in the top level project, you use:

install(DIRECTORY ${project_name_BINARY_DIR}/install_staging/ DESTINATION .)

Now CPack will package the entire staged install tree which should contain the installations of all the external projects.


- Chuck

On Mon, May 23, 2016 at 10:08 AM, Bruce Stephens <[hidden email]> wrote:
Sorry, that should obviously have gone to this mailing list.

---------- Forwarded message ----------
From: Bruce Stephens <[hidden email]>
Date: Mon, May 23, 2016 at 2:40 PM
Subject: Using CPack to package things not built using CMake
To: [hidden email]


Suppose I have a build which uses a number of external projects
(perhaps built using ExternalProject_Add) but which use a variety of
build systems.

And I want to package the result (so I arrange for the external
projects to build expecting themselves to be installed under
/opt/foo).

What are good ways to do that, without going in and replacing all the
existing build systems with CMake (which is likely the route we'll
take for some, but doing all doesn't seem practical)?

A possibility is just to build static rather than shared libraries;
for quite a few cases that would mean nothing would need to be
installed.

Another one (which would be a bit more general, I think) is to replace
the build with a CMake wrapper, so the building bit calls the
underlying build script but the install part is all done in CMake. In
these cases the numbers of files is usually quite small, so doing that
shouldn't be too annoying, and would presumably produce the right
scripts to use in CPack.

Any better ideas (or problems I'm missing with the last idea I suggest)?
--

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


--

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