[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: build two binary packages with different configure parameters

[I apologize for leaving this for two weeks, I moved house in the mean
time and was not online for a terrible lot of time]

On Sat, May 05, 2007 at 10:44:19AM -0400, Justin Pryzby wrote:
> On Sat, May 05, 2007 at 03:07:53PM +0200, Marc Haber wrote:
> > I have a package which uses debhelper at build time, and is built by a
> > rather simple configure - make - make install triathlon. As it fails
> > badly on xen, the xen people ask to provide a xen-enabled binary
> > package.
> > 
> > Thus, I need to build the package once with a normal configure, and a
> > second time with configure --with-extra-libs=foo. The rest of the
> > build process is identical.
> > 
> > All packages that I have seen which do this duplicate the entire build
> > process in debian/rules by having configure-foo, configure-bar,
> > build-foo, build-bar, install-foo and install-bar targets along with
> > all stamps explicitly doubled. I hate the idea of having to do this
> > with my package just to have a single different configure call.
> > 
> > Is there any more elegant way to do this? If so, which package uses it
> > that I can steal from?
> vim is referenced as a prototype for multiple binary packages with
> different compilation variations.  It's perhaps not clear from the
> large rules, but it really does handle 10+ such packages, and only
> calls configure once ("configure-stamp-%:", this is quite probably not
> portable make) and this includes a "make clean" to remove the
> earlier-compiled binaries objects and such for compilation of the
> current binary.

I agree that vim's build system is rather elegant. However, I fail to
see how to handle the case where the upstream sources are not in a
dedicated directory which can conveniently be moved away after
building a variant. 

I feel that the vim package might be "a number too large" to handle

Any more hints?

> Usually make is supposed to be as parallelized as possible; as such,
> rules that call $(MAKE) again are pretty inelegant.  However, for this
> case, you want to avoid parallelizing it: the compilations must be
> serial not concurrent.

Yes. I assume that all packages that build multiple variants of a
package do so sequentially.


Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

Reply to: