[CMake] Deb and RPM package generation modules

Eric Noulard eric.noulard at gmail.com
Wed Jul 4 12:48:48 EDT 2007


2007/7/4, Mehdi Rabah <mehdi.rabah at gmail.com>:
> Hi everyone,
>
> In case someone is interested in linux package generation within cmake,
>  I've started to improve the existing scripts
> (http://www.cmake.org/Wiki/CMakeUserUseRPMTools
>   and http://www.cmake.org/Wiki/CMakeUserUseDebian)
>  to make both debian and rpm packaging easier.

This is a good idea, easier is better :)) [most of the time though]
I did file a feature request for including UseRPMTools.cmake in cmake distro:
 http://www.cmake.org/Bug/bug.php?op=show&bugid=5191&pos=0

may be you may attach your files to the tracker and comment on
your modifications as you did here.


>  The differences with the original scripts are that:
> - you can customize the entire control or spec file directly
>     from your cmake file (yet to finish for rpm)

Good I did not take/find time to do this.

> - it doesn't need cpack anymore (I don't know if it's a good thing or not)

I think it is not a good idea but I will come back on this at the end.

> - the two modules have some common description variables
>     (so it's easy to describe both rpm and deb packages)

A good point those "commons" should be handled by CPACK I think.

> - you can generate a package for each subproject (ie folders with a
> CMakeLists
>    and a PROJECT() macro) of your cmake project.

Interesting I will try this.

> - can't generate the source package anymore :/  (yet)
>    this was made using cpack, but It seems that cpack don't let you choose
> what    do you want to put in your source package...

not entirely try since you may set
CPACK_SOURCE_IGNORE_FILES  for a list of to be ignored source files.
I personnally use:
SET(CPACK_SOURCE_IGNORE_FILES
"/CVS/;/\\\\.svn/;\\\\.swp$;\\\\.#;/#;.*~;cscope.*")

However this issue is a real one and it
was previously discussed on the list with no conclusion (I think).
It seems necessary to be able to indicate which
(source) files should be shipped by cpack.
The fact is that for binary package it's easy, just make install
for source package I think one need both
rules for exclusion (as with CPACK_SOURCE_IGNORE_FILES)
AND
rules for inclusion, may be based on something like the EXTRA_DIST
of Autotools which have to be specified in each CMakeLists.txt.

> so I'm trying to do it
> without cpack
>    (btw, there is very really few documentation on cpack ^^)

True :))

>
> So I think that's it. Do you have any thoughts on all this?

Yes I do keep reading :))

> CPack seems to have some cool feature like stripping binaries,
> so do you think it will be a good idea to *really* integrate these modules
> within cpack?

I think CPack should be improved in order to generate "clean"
binary AND source packages for "raw archive" generators:
STGZ, TBZ2, TGZ, TZ, ZIP.

Concerning more "intelligent" package format like:
rpm, deb, nsis, or whatever other formats which needs more
informations than a list of files I think it  should be implemented
using CMake macros like the one you did BUT built on top of
cpack "raw" archive formats.

We should agree on a common set of variables
PACKAGE_xxxx or CPACK_xxxx like the one you
proposed + package format specific vars depending on the
specific generator needs.

As a last remark I think you forget something in the
"User specified spec file" case you only copy the file:

ADD_CUSTOM_COMMAND(
        OUTPUT ${SPEC_FILE}
        COMMAND  ${CMAKE_COMMAND} -E copy "${ARGV1}" ${SPEC_FILE}
        COMMENT  "Copying user specified spec file : ${ARGV1}"
      )

whereas I did run configure on the file if it has ".in" extension.
see:
http://cvs.savannah.nongnu.org/viewvc/tsp/make/UseRPMTools.cmake?root=tsp&view=markup

I think it is really important for the "advanced" user to provide its own spec
(or other set of package maker input files) which may be automagically
CONFIGUREd by cmake. Because in those files you usually needs information
which is only available to CMake.

May be the ".in" extension discrimination is a bad idea and should be
transformed in an extra (optional) argument to ADD_RPM.


-- 
Erk


More information about the CMake mailing list