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

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to