[CMake] Creating two distinct packages w/ CPack from a single project

[Eric Noulard]

Le 16 oct. 2017 23:54, "J. Paul Reed" <preed at releng-approaches.com> a
écrit :


Hey all,

I have a (potentially?) odd situation: I need to generate multiple packages
using CPack from the same CMake project.

I'm aware of the component-based installers and methodology, but I don't
believe that's what I want here: I want entirely different package
names/versions/etc., containing different artifacts created from a single
CMake project.

I have currently implemented this by setting the various CPack
configuration variables, and then include()ing CPack in different
directories. I then have custom targets that call cpack with --config,
pointed to a non-default-named CPack configuration file.

This seems to work just fine, except during the cmake configuration run, we
get warnings about CPack.cmake having already been included.

I see where this message() gets emitted
(https://gitlab.kitware.com/cmake/cmake/blob/master/
Modules/CPack.cmake#L298-302);
perusing that file, it seems to do things I basically want/need (setting
various defaults, etc.) if I want to use cpack with a different config
file.


Hi there,
As you already discovered I was the author of this warning some years ago
when I was actively working on CPack. The reason for this was to make it
clear that even include(CPack) may look (and somehow behave) like a
function call creating a CPack config set of files. It is not. It wasn't
designed for that usage and it may generate weird content on a second (or
more) inclusion.
Some people were occasionally bitten by that.
e.g. since it inspects variable (in the current scope which was initially
global) beginning with CPACK_ prefix for doing its work, when you use it
twice it does not ensure or cleanup variables that may be there due to the
first inclusion. This would be up to the user to clean leftover before
successive inclusion.

To summarize, this is a pure macro processing, not a function call.

It would be nice to have a cpack_xxx function which safely implements the
behaviour you seek. That was on my wishlist some time  but I never get the
time to implement it. (There may be some old mantis bug report for that
wish, I'll dig into it and come back here if I find something interesting).


I can suppress the warning by unsetting CPack_CMake_INCLUDED, which is what
I'm planning to do... but I wanted to ask:

a) whether there are any technical problems or concerns by subverting that
warning message and including CPack.cmake multiple times, and


You can now that you know the story. If I would have to do that I would:

1. Delete **all** CPACK_ variable from current scope

2. Unset CPack_CMake_INCLUDED

3. setup the new CPACK_xxx value set

4. include(CPack)


b) if there's another solution entirely that is better suited. (Again, I'm
aware of component based installs; I don't think they'll do what I want
here.)



Yep, contribute a "real" CMake function that do the right job.
Ideally this function should replace current include(CPack) usage.

CPack.cmake should be kept for backward compatibility legacy reason but
it's content should be replaced by the appropriate new function call.



thanks,
preed
--
J. Paul Reed
--

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/20171024/a55b7b7f/attachment.html>