[CMake] How to request features?
Eric Noulard
eric.noulard at gmail.com
Fri Aug 3 12:32:53 EDT 2007
2007/8/3, Alexander Neundorf <a.neundorf-work at gmx.net>:
> On Friday 03 August 2007 09:49, Christian Convey wrote:
> > On 8/3/07, Alexander Neundorf <a.neundorf-work at gmx.net> wrote:
> > > Currently we are in the process of migrating from phpbugtracker to
> > > mantis, so better wait a few days until everything is working again as it
> > > should.
> >
> > OK, will do.
> >
> > > P.S. which feature ?
> >
> > Request #1:
> > My project produces multiple Debian (and soon, RPM) packages. I'd
> > like to not have to reconfigure the project for each .deb/.rpm package
> > my script is about to produce.
> >
> > So the request is to be able to easily control (in a supported way)
> > which installation component(s) will be installed when you run "make
> > install".
>
> Is this for packaging ?
> CPack supports installing single components via CPACK_INSTALL_CMAKE_PROJECTS.
> If that's not what you need please explain.
> Here's an example:
> http://www.cmake.org/cgi-bin/viewcvs.cgi/ParaView3CPack.cmake?rev=HEAD&root=ParaView3&view=auto
>
> > Request #2: (If not already true) ensure that CPack supports *all* of
> > the fields from Debian control files, such as dependency lines.
>
> Have a look at Modules/CPackDeb.cmake, there is a DEBIAN_PACKAGE_DEPENDS. Does
> this what you need ?
>
> > Request #3: Provide an RPM generator for CPack (and ensure it supports
> > all important fields, such as the dependency list).
>
> Patches are welcome :-)
> A problem with the rpm macro is that it builds the package again instead of
> using the already built install tree.
That's a fact :))
I did this because I followed the steps used by others
RPM-packaged softwares using autotools which "just does this".
For an Source RPM this is the only way you may rebuilt binary package
on your own box, because CMake config step may discovered
different thing on the box the binary RPM is built on.
> The generated cmake call for the srpm
> file:
> cd build_tree
> cmake -DCMAKE_INSTALL_PREFIX=%{rpmprefix} ../%{srcdirname}
> make
>
> also doesn't support additional options to cmake. Maybe the current
> CMakeCache.txt could be used for building the binary rpm:
> cmake -C
> ${CMAKE_BINARY_DIR}/CMakeCache.txt -DCMAKE_INSTALL_PREFIX=%{rpmprefix} ../%{srcdirname}
>
> But this would break for the source rpm, since when building this there is no
> CMakeCache.txt.
Exactly you get it.
> How are srpms supposed to handle this ? The configure scripts may need
> additional arguments, same for cmake here.
I don't really know I think your spec file contains "standard" options
and you will have to change the "standard" spec file and rerun
rpmbuild -bb you_modified_spec_file.spec
in order to get the custom optionized RPM.
> What does rpmbuild do ?
> Is it more than packaging the install tree together with some special files ?
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.
Try UseRPMTools on a Fedora box for packagin CMake itself
and you will see what happen.
rpmbuild effectively does the install step in a chrooted environment
which is interesting to catch faked-install error.
When building binary packages rpmbuild computes binary packages
dependencies.
I'll may send you a log of an rpmbuild run as an example.
I'll try to generate CMake rpm for FC6 and put it somewhere.
I'll try it tonight or tomorrow since I'm running ouyt of time just now :))
As a summarized explanation for why I did UseRPMTools this way:
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.
--
Erk
More information about the CMake
mailing list