[CMake] RPM CPack generator, was: How to request features?

[Alexander Neundorf]

Hi,

On Saturday 04 August 2007 15:58, Eric Noulard wrote:
> Re-send to the list because previous attached files were too big.
...
> rpmbuild take RPM building specification file (the .spec file)
> which contains [among other things]
> explicit dependencies given by the user who wrote the .spec,
> the list of file to package and the list of file to install.
>
> Requires:       pkgconfig
> BuildRequires:  cmake libxml2-devel gtk+-devel fuse-devel   glut-devel
>
> Requires directive describes the binary package dependencies
> BuildRequires describes the build dependencies, the package needed
> for building binary RPM.

I think the BuildRequires are not required when creating a binary RPM with 
cmake, because at that time the project has already been built.

> Using this informations rpmbuild may add dependencies in the
> binary RPM package which are specific to the distributio
> like the needed version of glibc.
> You may ask rpm to print the list of dependencies with
>
> rpm -qp --requires <binary_package>.rpm
> some of the requires may be provided by the package itself
> as shown by
> rpm -qp --provides <binary_package>.rpm
>
> > > Try UseRPMTools on a Fedora box for packagin CMake itself
> > > and you will see what happen.
>
> I've attached a patch for current CMake CVS version
> plus an Updated UseRPMTools.cmake which is OK to build
> CMake RPM.
> UseRPMTools.cmake should go in CMake/Modules/.

I don't think we'll add this as it is to cmake cvs. It should be a cpack 
generator (see below).

> I successfully tested it on a Fedora Core 6 box.
> The log corresponding to
> make VERBOSE=1 cmake_rpm >& CMake_rpm_build.log
> because it was too big for the list, ask me if you need it.
>
> You can see the content of the obtained RPM using
> rpm -qpl cmake-2.5.0-1.i386.rpm
>
> as you may see if you have a Fedora box you end-up
> with 2 RPMs
> cmake-2.5.0-1.i386.rpm
> cmake-debuginfo-2.5.0-1.i386.rpm
>
> the last one containing non stripped binaries.
> This is the behavior of rpmbuild on FC6.
>
> > > I did stick to CMake MACRO + rpmbuild (instead of
> > > trying to improve CPack code) precisely because I'd
> > > like to trust what rpmbuild does and to simply ignore it
> > > instead of tracking rpmbuild work evolution
> > > (which may be different on FC6, FC7, Mandriva 200x ...)
> > > in order to put it back to CPack.
> >
> > Ok.
> > I think it's ok to use rpmbuild, but it would be nice if for the binary
> > package rpmbuild could used so that it actually packs the install tree
> > instead of building and make install itself. Can this be done via
> > special %prep, %build and %install steps ?
>
> Yes I think it should be possible, and i'll try to do it and keep
> you informed.
> Nevertheless, you must keep in mind that the currently
> generated .spec file is unique and used both for binary and source package.
> I may need to generate 2 differents specs files for achieving what
> you want.

Yes, it seems so. The one for the source RPM would be a full regular spec file 
as far as I understand.

The one for the binary would have to be quite special.
How does rpmbuild do the packaging ?
Does it compress the installed tree or does it catch the install commands and 
record this way what is installed ?

If it compresses the installed tree, then it should be possible to create such 
a spec file, which doesn't actually build the project again and which also 
doesn't execute make install again, but which "only" compresses the install 
tree. If you have a look in ${CMAKE_BUILD_DIR}/_CPack_Packages/, you will 
notice there are install tree for every package generator. Such an install 
tree will also be generated if we add a RPM generator. Can you tweak the spec 
file so that it just compresses this tree ?

I think it would be also ok to skip the cmake and make steps during building 
the binary RPM and just executing "make install", probably with DESTDIR set 
to some location where it fits with rpmbuild.
Can you try to get this working manually ? 
If this or the step above works, I'd like to add this as a generator in CPack 
(for more see below).

> > This would mean that the rpm is not created by building the previuosly
> > created source rpm, but independent from it.
>
> Litteraly the binary RPM is not built after building the source RPM,
> but the 2 RPMs binary AND source are built using a source tarball
> generated with cpack -G TGZ --config CPackSourceConfig.cmake.
> the resulting tarball is put in ${RPM_ROOTDIR}/SOURCES.
>
> RPM_ROOTDIR is set by UseRPMTools to be ${CMAKE_BINARY_DIR}/RPM
> with the usual RPM subdirectories tree:
>
> RPM/
>
> |-- BUILD
> |
> |   |-- build_tree
> |
> |   `-- cmake-2.5.0
> |-- RPMS
> |   `-- i386
> |-- SOURCES
> |-- SPECS
> |-- SRPMS
>
> `-- tmp
>
> The strange thing here is that RPM_ROOTDIR is currently a subdir
> of the current CMake build_tree giving the strange thing you've noticed
> 2 complete and may be differently configured build tree.

...
> > If this is implemented as a generator in cpack it still can use rpmbuild,
> > there is nothing which speaks against this.
>
> Yes you are right again.
> My personal point of view regarding CMake feature is the following
> "If I may implement the needed feature with CMake MACRO
>  then I'll go for it".
>
> Adding feature in the compiled CMake code is adding more
> work for Kitware and less power to change/update the feature
> to user (i.e. me :))
>
> Regarding CPack  I would say that it almost have all what I need
> and the missing package format I need I would rather
> implement them as CMake macro than compiled/built-in generator.
>
> For example could you tell me what's the benefit of
> implementing NSIS Generator as a built-in CPack generator?
> As far as I undertand you use the NSIS template file + some
> var replacement that could be done with CONFIGURE_FILE
> then you invoke the NSIS tool, or am I wrong?
>
> And please don't take this question as a pure critic of
> the work you and/or other have done.
> I'm just trying to understand the pro/cons of the approach
> and your point of view regarding what should be
> implemented in CMake C++ source code and
> what should implemented as a CMake macro.

Since two weeks or so CPack can also execute cmake scripts, this is now partly 
used in the ZIP and Debian generators. They use it "only" to set up variables 
and find stuff. It could also be used to call execute_process() or 
file(MAKE_DIRECTORY ...) etc. You can't use ADD_CUSTOM_COMMAND() or 
ADD_CUSTOM_TARGET() there.

We could do the following: I add a CPackRPMGenerator.cxx which executes a 
cmake script (something like Modules/CPackRPM.cmake), and you can put most of 
the logic in that script file.

In CMake it is currently possible e.g. to add languages without modifying the 
C++ sources. CPack needs some work to get to such a stage where you can add 
package generators by just modifying some scripts.

Bye
Alex