[CMake] CPack integration

[Dennis Schridde]

On Monday 02 August 2010 00:17:53 Eric Noulard wrote:
> My personal point of
view with your idea is that
> since we most most probably want to maintain
backward compatibility
> it would even be better if we can do
> 
> 1 -
set(CPACK_...
> 2 - include(CPack)
> 3 - set(CPACK_...)
> 4 -
cpack_update_config() or cpack_reconfig()
> 
> that way 1, 3 and 4 are
optional just as today.
> 3 and 4 would bring what you suggest.
Another
option could be:

include(CPack)
cpack_configure(CPACK_... xxx CPACK_... yyy
...)

That way the CPack module would know for sure which values the user
wants to set, and which ones have to be filled with automatic
contents.

This also should not clash with backward compatibility, because
first include(CPack) could setup everything with the dummy values it uses
now.
When cpack_configure is called, it would know exactly what to
overwrite, and where to set default values.


Btw, I think the dummy values
(e.g. version and vendor) CPack.cmake sets atm are not really helpful. They
just cloak any mistakes the user made by forgetting to set some CPACK_...
variable. The values should either be required and empty by default,
generating an error if forgotten. Or they should be constructed from the
other variables with a sensible content.

E.g. I would assume not setting
VERSION_PATCH would make CPack just leave it out, generating a version like
x.y only. But instead it automatically appends a .1 everywhere. Totally not
my intention.
Same goes for vendor=Humanity. I expected I could leave the
variable out for now. Instead of using the empty string (or nothing, it's
really not needed when producing a binary or source tarball) CPack filled it
with some junk.


--Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100802/8b8c50a3/attachment.pgp>