2011/1/11 Michael Hertling <mhertl...@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
_______________________________________________
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
