[CMake] Fwd: Using CPack to package things not built using CMake

Chuck Atkins chuck.atkins at kitware.com
Mon May 23 10:21:37 EDT 2016


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 <bruce.r.stephens at gmail.com
> wrote:

> Sorry, that should obviously have gone to this mailing list.
>
> ---------- Forwarded message ----------
> From: Bruce Stephens <bruce.r.stephens at gmail.com>
> Date: Mon, May 23, 2016 at 2:40 PM
> Subject: Using CPack to package things not built using CMake
> To: cmake-developers at cmake.org
>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160523/8526dd68/attachment-0001.html>


More information about the CMake mailing list