[CMake] CPack and configure_file

[Eric Noulard]

2011/1/11 Michael Hertling <mhertling at online.de>:
> On 01/11/2011 09:48 AM, Eric Noulard wrote:
[...]
>> The fact is CPack doesn't know much about "source package" and
>> in fact it package source using the CPACK_INSTALLED_DIRECTORIES directory list.
>> (look at the generated CPackSourceConfig.cmake)
>>
>> I think you can "emulate" the extra thing of autoconf.
>> If you want ot package "more" than the source tree with
>> "package_source" you can try
>> the following in your main CMakeLists.txt (before include(CPack))
>>
>> SET(CPACK_SOURCE_INSTALLED_DIRECTORIES
>> "${CMAKE_SOURCE_DIR};/;${CMAKE_BINARY_DIR}/extra;/extra")
>>
>> then the content of the directory
>> ${CMAKE_BINARY_DIR}/extra will added in the package source archive
>> inside "extra" dir.
>>
>> it should work.
>
> Indeed, it does; thanks for this hint, Eric. :)
>
> Just two remarks about that solution from my side:
>
> 1) Is it an official feature? The CPACK_SOURCE_INSTALLED_DIRECTORIES
>   variable is not documented anywhere and does hardly appear on the
>   ML or the BT, and even G**gle says that it is used rather seldom.

As official as the content of CPack.cmake  is :-]
CPack documentation is lagging but help is welcomed:
http://public.kitware.com/Bug/view.php?id=10067

> 2) In contrast to the usual "package" target, there is no dependency
>   of "package_source" on "all", so one will possibly miss something
>   if the source package ingredients need to be set up at build time.

This is pretty right.
But like I said, my opinion is that source packaging with CPack is
nothing near like a builtin feature because it only takes the content of
some directories and that's all.

There is no prerequisite to the package_source target because
of the implicit (my opinion) assumption that source tree==package source
and  source tree does not contains non-generated files because build tree does.

I would rather add some more "explicit" support using explicit vars
with common prefix like:
CPACK_SOURCE_xxx

Each such var should have clearly defined behavior.

> AFAICS, the latter can be addressed with CPACK_INSTALL_COMMANDS set to
> "${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR}" or whatever is necessary
> to prepare the source tree for packaging, but there's no source-package
> specific CPACK_SOURCE_INSTALL_COMMANDS variable or the like. Perhaps,
> this is worth a feature request as concerns like the OP's one, i.e.
> the addition of certain build-time generated files to the source
> package, are somewhat reasonable, IMO.

Even CPACK_SOURCE_INSTALLED_DIRECTORIES is not really a full blown
CPACK_xxx var.
The  cpack application does not use it at all.
cpack only uses CPACK_INSTALLED_DIRECTORIES but CPack.cmake
uses CPACK_SOURCE_INSTALLED_DIRECTORIES in order to create the default
CPackSourceConfig.cmake.

Try a diff between the generated
CPackSourceConfig.cmake
and
CPackConfig.cmake

you'll see what I mean.

CPack itself (the application) does not even know what a "source package" is....
CPack only knows "CPack generators" (TGZ, RPM, DEB, ZIP, PackageMaker, ...)
and differents ways to "install" something:
CPACK_INSTALLED_DIRECTORIES
CPACK_INSTALL_CMAKE_PROJECTS.


My summarized opinion is that if ones wants some clean feature to
package "source"
then this must be designed from the ground-up knowing current CPack behavior.

Current source packaging is more or less a hack.
Useful hack, but a hack.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org