[CMake] How to request features?

[Eric Noulard]

Re-send to the list because previous attached files were too big.

2007/8/3, Alexander Neundorf <a.neundorf-work at gmx.net>:
> On Friday 03 August 2007 12:32, Eric Noulard wrote:
> >
> > Yes there is more.
> > I throw hereafter the things I know, but there may be more.
> >
> > It checks whether if every package file are installed and conversely.
> > Depending on the distribution flavor (Fedora, Mandriva etc...)
> > it will automagically build additionnal package used for debug.
>
> rpm or additional tools like yum ?

Sorry but I think my poor english leads to misunderstanding.

yum (FCx), urpmi (Mandriva) tools do manage RPM package
dependencies with the dependencies informations stored inside
the RPM itself. Such tool kind-of proposes or
generates "rpm" commands (man rpm for détail)
you'll have to do manually if you had only the genuine
"rpm" command.

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.

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 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.

>
> 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.

>  It would also mean that the binary
> package is exactly what you have built with the exact cmake settings, which
> would be a good thing.

Yes that's true, it would be a good thing. I'll try this soon.
In order to ease this it may be nice to have a way to know how
CMake was called for the current build tree or does
make -C CMakeCache.txt do the trick?

> 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.

Note that implementing more CPack generator using MACRO
does not prevent them to appear in the
cpack --help
list of supported generators.

We may "just" have to fix what should be a CPack generator macro file,
may be a file naming scheme like

CPackGen<GeneratorName>.cmake

and a set of CMake vars the Macro file should define.

I'll come back to you with more test with RPM generation
using current build tree.


-- 
Erk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMake_RPM.patch
Type: text/x-patch
Size: 865 bytes
Desc: not available
Url : http://public.kitware.com/pipermail/cmake/attachments/20070804/af104600/CMake_RPM.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UseRPMTools.cmake
Type: application/octet-stream
Size: 5936 bytes
Desc: not available
Url : http://public.kitware.com/pipermail/cmake/attachments/20070804/af104600/UseRPMTools.obj