Re: question on conditional'd spec files

[Gregory Leblanc <gleblanc linuxweasel com>]

On Fri, 2001-12-21 at 07:04, Thomas Vander Stichele wrote:
> Hi,
> 
> I'm fixing build stuff for GStreamer (http://gstreamer.net)
> 
> Now, currently, we have one large spec file which generates close to 40
> RPM's.  As you can imagine, the build takes quite some time, and it is
> really disheartening to have the rpm building fail because of one badly
> spec'd or badly coded plugin.  This is of course a major issue in quality
> testing (automatic building at night) and when close to a release.

Holy smokes!  40 rpms?!?!  And I gave the nautilus folks grief for their
7...  Does this all come out of the same source tree/tarball?  Has
anybody looked into breaking it up into separate tarballs that can be
built separately?  This might also ease distribution in source format. 
Even if it wasn't per-plug, one tarball per group of related plugins
might be interesting.  This would be the route that makes the most sense
to me.  Must be time to get together with Erik for a beer again...

> Now I have taken a few steps to remedy this, but I would like some ideas
> since I'm not sure what route to take.
> 
> First of all, I have started adding --enable options for all of the
> plugins and libraries, so that I can decide what to turn on and off at
> build time.  For the mad plugin, this is for example done by defining a
> USE_MAD in configure.ac
> 
> in gst-plugins.spec.in, I prefix each line pertaining to the mad package
> with
> @USE_MAD_TRUE@
> 
> This way, the package spec only ends up in the spec file when it's
> actually being used.  This will take a lot of work, however, so I was
> wondering how other, similarly large, packages handle this issue.

That's an interesting approach, though clearly lots of work.

> This approach is supposed to give us a few advantages.
> 
> a) in configure.ac, we can easily list a few of the plugins as
> experimental or broken, so when we roll the tarball these parts of the
> spec file will not be generated and thus it is easy to get all of the
> rpm's to build that we are sure that work.
> 
> b) by writing a small script, we can easily regenerate tarballs with
> different USE_... vars defined.  This way we can repeatedly create a
> tarball that will only build one plugin/package, build an rpm from that,
> and repeat this cycle.  This way we can actually test what parts of the
> whole source code/configure/spec part are mapped out right when the time
> is nigh for a release.
> 
> Another question I have is: am I making this too hard ? Are there options
> I can use in the spec file that make this easier, or does rpm provide for
> sequential building ?
> 
> If any of this makes sense to you, and you have information to share or
> stuff to comment, then please do ;) I'm looking to learn some more ...

It makes sense, but this is a really complex way to go.  If you really
want to stick with a single monolithic tarball, I think you've got a
pretty decent strategy here, though I fear it will me maintenance hell.
	Greg
GNOME Packaging Project

-- 
Portland, Oregon, USA.