[CMake] Building source RPMs?

[Eric Noulard]

2010/8/5 Alexander Neundorf <a.neundorf-work at gmx.net>:
> On Thursday 05 August 2010, Magnus Therning wrote:
>> On Thu, Aug 5, 2010 at 10:39, Eric Noulard <eric.noulard at gmail.com> wrote:
> ...
>> > What is your usage pattern?
>>
>> We ship most of our sources as source RPMs since most of our changes are
>> added patches to upstream (CentOS) RPMs.
>>
>> It is just nice to also ship the source of our own code as RPMs rather than
>> as tar-ball.  However, I don't see a big problem with simply dropping use
>> of CPack and writing the SPEC files manually.  It would just be a
>> nice-to-have is all.
>
> Somehow I don't really understand how a source RPM or source deb generator
> would make sense for CPack.
> E.g. a source deb is the plain source package, plus an optional patch, plus a
> file which describes how to build it.

Yes a complete RPM spec file which may be used both for binary and source
RPM describes just that, a plain tar file, may be a bunch of patch files, then
some rules to build and install from source
(from the tar which will be automagically patched by rpmbuild).

You are right when you say that it does not make much sense to build
a source RPM with CPack but CPack is able to build a source tarball/zip etc...
CPack is able to build a binary RPM, thus
people expect it can build a source RPM too.

In fact CPack does "part of the job" of any "package build tool" like
the rpm/rpmbuild command or dpkg-xxxx commands.

> IMO the patch would be always non-existent if generated with CPack (since this
> generates the package directly from the original source tree),

You can perfectly imagine that you use upstream source tree +
separates patchsets (in Your own source tree)
and use CMake+CPack to build the whoel thing.
It seems to be the case described by Magnus.

However even if the patch set is non-existent it can be useful to have
a source rpm,
but keep reading.

> so the only thing left would be to generate the spec file.

Yes that's true but I think that for many people not writing their spec files
(or deb control data) is of great interest.

> I guess for a source RPM it's similar ?

Yes it is.
The thing is with a source RPM the user (who get the source RPM)
can rebuild a binary rpm using:

rpmbuild --rebuild your.src.rpm

it doesn't have to know whether if the software is using CMake or configure
or whatever to build. All this should be specified in the [source] spec file.

this type of action will
1) unpack the content of the source rpm
2) untar + patch  the sources
3) configure the source for building (may be with cmake or configure)
4) build (make)
5) install (make install)
6) build the binary RPM by packing

So generating a "source spec file" that would be usable to build
a source package is definitely possible. In fact this was done
by the UseRPMTools.cmake
http://www.cmake.org/Wiki/images/9/94/UseRPMTools.cmake
look at ADD_CUSTOM_TARGET(${RPMNAME}_srpm rule.

But again you are right this cpack done with a cpack generator
the rule was only using cpack to build the source tarball.

The main difference between CPack and rpm/deb tools is that CPack
does know the difference between "source" and "binary" package.

The "package_source" rule is "just":

cpack --config CPackSourceConfig.cmake

and the CPackSourceConfig.cmake is using
"CPACK_INSTALLED_DIRECTORIES"
but not
"CPACK_INSTALL_CMAKE_PROJECTS"

whereas  "package" is:

cpack --config CPackConfig.cmake

and CPackConfig.cmake is using
"CPACK_INSTALL_CMAKE_PROJECTS"
and not
"CPACK_INSTALLED_DIRECTORIES"

so you MUST have TWO differents "CPack config file" for describing
how to pack binary or sources. This is not the case for RPM
the spec file (i.e. RPM config file) is/may be the same for source or
binary RPM.

So if you continue to follow me until the end,
it would make sense for CPack to build a source RPM either if
CPack has knowledge that it has to build a source package or
if we write a "separate" generator whose purpose is to build the source package
something like a CPackSRPM.

Would it be worth the needed work to do it, I don't know :-)

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