[CMake] Debian, Redhat, and Cygwin packaging

[Alan W. Irwin]

On 2006-12-11 20:42-0800 Brandon J. Van Every wrote:

> Someone showed up on the Chicken mailing list and wants to do Debian 
> packaging for Chicken.  I'm looking at what I need to do to support packaging 
> systems "in general."  I've noticed several problems already:
>
> - packages tend to duplicate the project's manifest.  Often these 
> duplications are maintained by hand, which means they break when someone 
> changes something in Chicken proper.  So I am thinking that CMake will have 
> to emit some kind of standard manifest that packages can use.

For PLplot the manifest of what files are installed depends strongly on what
cmake options are chosen by the packager and which of the build dependencies
are installed on his machine.  (PLplot has tons of different options and
accompanying build dependencies.)  It would certainly be useful to our
packagers for "make install" to automatically generate a complete manifest
of all installed files.

>
> - packages tend to assume that everything is done with ./configure.  Not sure 
> yet if it's a technical problem,

I don't think there are any technical issues.  I have had one rpm packager
working with our new CMake build system for PLplot, and he is not having too
much trouble with it.

> but it is a political problem.  For 
> instance, Chicken currently supports both CMake and Autoconf builds, but only 
> CMake is supposed to be used for making distros.  But volunteers see the 
> Makefile.am and go to town on it.  This means CMake-built code isn't getting 
> deployed, which is very much counter to my testing and adoption goals.

I agree it is a political problem, and those software projects who are
making the transition from autotools to CMake will probably want to include
the autotools option to ease the transition.  For example, PLplot is
continuing with deploying all the autotools files in our release tarballs,
and it appears you are doing the same thing with Chicken.

What we are telling our users, though, is the autotools approach is
deprecated because we cannot find any volunteers who want to maintain it
(which is the truth and also the major motivation for our switch to CMake),
and certainly none of our new development features will be accessible for
those poor lost souls (actually we used words slightly more diplomatic than
that) who continue to use our autotools build system.

Our latest development release (unadvertised except on our mailing list)
featured the new CMake build system, and we have been averaging 20 downloads
a day for the last 15 days as our users give it a spin and word of mouth
gets out about it.  Of those ~300 downloads, we got one minor complaint
(about incorrect documentation of the minumum CMake version), but that is
the only feedback!  I guess PLplot users are all strong, silent types....
:-)

So I have no clue whether they have all switched to our CMake build system
and are happy with it (aside from that one minor complaint) or whether they
are automatically using the ./configure script out of habit and completely
ignoring what we said on the PLplot list about the reason (widespread
testing our new CMake build system) for this development release.

So it goes.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________