Re: The Super-Ultra-Mega Build Idea

[Bill Mitchell <mitchell@mdd.comm.mot.com>]

Bruce said:

> You should really be able to extract each .tar.gz, cd into the source
> directory just extracted, and build with
> './debian.rules binary CFLAGS="..." LDFLAGS="..."' and have it work the
> first time, using the CFLAGS and LDFLAGS you pass on the command line.
> If LDFLAGS doesn't contain "-s", debian.rules should not strip the
> executables. If your debian.rules or Makefile uses an explicit "strip"
> command, simply test for if ( $(findstring -s,$(LDFLAGS)) ) before
> invoking it. If CFLAGS contains -m<architecture>, that should be honored.
> -m<architecture> should be passed to other language compilers from CFLAGS.
> GNU make has all of the string-transformation functions to make that simple
> to do.

I think we may be mixing too many things in the wrong size pot here.

I've occasionally built debugging versions of programs in my
packages, and done it by twiddling the CFLAGS and LDFLAGS lines
in debian.rules.  If the packaging guidelines had said that debian.rules
should allow invocation-time redefinition of these vaviables, I'd
have built my debian.rules files that way, and might have twiddled
CFLAGS and LDFLAGS from the invocation line instead of twiddling the
debian.rules file (then again, I might not have -- I'm not a fan of
complex, difficult, and error-prone invocation command lines).

Regarding stripping executables, I've seen debian.rules files
which use "install -s" to do that -- which is conceptually pretty
far removed from "LDFLAGS="...". 

Also, I've seen debian.rules files and upstream package package Makefiles
with pretty complicated CFLAGS defs -- not something I'd like to type
in from an invocation command line.

Also, I've seen packages which use different compiler flags to build
different parts of the package.

Also, I've seen upstream packages where it'd take serious surgery on
the upstream maintainer's build scheme in order to support passing CFLAGS
and LFLAGS in from a front-end debian.rules file.  (And, in general,
I'm a strong believer in touching the upstream package content as
lightly as possible).

I think what you're shooting for here might belong at a higher level of
abstraction than CFLAGS="..." LDFLAGS-"...".

Perhaps instead of CFLAGS="...", it'd be better to mandate support of
"[ ARCH=archname ]", defaulting to i386 if absent, and failing the build if
archname is specified as a value not explicitly supported in debian.rules.

Perhaps instead of "LDFLAGS", it'd be better to have "[ STRIP={ YES | NO } ]",
defaulted to one or the other if not specified.  (Which default?  I've
been wondering how good those 3X package size difference estimates were,
what with "gzip -9" being involved, and with executables being <100% of
the package contents.  Just out of curiosity, I may try building few
packages with stripped vs. unstripped executables tonight and see what
actual package size increases I see with the unstripped executables in.

Anyhow, getting back to your suggestion, a bit out of sequence:

> [...] I consider it
> an independent project for one person who is interested in doing the
> work, not coupled to any particular release schedule. Of course this
> person would need the cooperation of all package maintainers to insert
> patches to debian.rules and their Makefiles. I'd sure like to hear from
> someone willing to come forward and take it on.

I'd suggest restating the mandate.  Whoever takes this on will be re-examining
the packaging guidelines and recommending changes to support build-time
specification of target architecture, stripped/unstripped executables,
(and possibly other matters?).