[gst-devel] rpm build problems

[Richard Boulton]

On Mon, Jun 04, 2001 at 03:23:49PM +0200, Arnd Bergmann wrote:
> OK, the RPM build works fine now, but the compiler optimization
> flags are still mostly nonsense. I have made two patches that
> correct this. 

> The first simply appends $RPM_OPT_FLAGS or -march=$target_cpu
> to $CFLAGS and should cause no problems but a noticable speed up. 
> Note that 'CFLAGS=$RPM_OPT_FLAGS ./configure' did not work because 
> $CFLAGS is cleaned at the beginning of configure (is this a bug 
> or a feature?)!

I think it's a bug.

The whole situation with CFLAGS and things is very messy.
In fact, Makefiles should never touch CFLAGS: they should instead set
AM_CFLAGS which is used alongside CFLAGS.  configure.{in,ac} should
also not set CFLAGS (though it may alter them temporarily while doing
tests: it should set them back afterwards)

The user can then do:

"CFLAGS=foo make", or
make CFLAGS=foo, or
CFLAGS=foo ./configure, to set flags to be used, without interfering with
the configured flags.

The whole policy should be:

 1)  configure scripts should not set the value of CFLAGS (except
     temporarily while doing tests)
 2)  instead, configure scripts should detect the CFLAGS needed to use
     each configured package, and store them in an AC_SUBST variable,
     such as GSM_CFLAGS.
 3)  Makefile.ams should never set CFLAGS
 4)  instead Makefile.ams should set AM_CFLAGS to the values required
     in that subdir.  [If the CFLAGS are specific to only a single target,
     as happens in the gst/ subdir currently, the only clean fix is to
     wait for automake 1.5 which supports target specific CFLAGS].

 finally, and possibly controversially:

 5)  Makefile.ams should only ever set AM_CFLAGS to a combination of
     *_CFLAGS variables.  These variables are defined in configure.base,
     so this keeps the definition of special flags in a single file, which
     should be more maintainable.  There should first be a set of flags due
     to the dependencies of code in that module, and then (optionally)
     flags specific to that module.

     For example, if we suppose that the colorspace module needs the
     -ffast-math flag defined, we put this in COLORSPACE_CFLAGS in
     configure.base, and then put
     AM_CFLAGS = $(COLORSPACE_CFLAGS) in configure.base.

     another module, foo, might have
     AM_CFLAGS = $(GSM_CFLAGS) $(X_CFLAGS) $(FOO_CFLAGS)

     and another one, bar, which has no special flags needed, might have
     AM_CFLAGS = $(ESD_CFLAGS)

oh, and
  6) Whenever custom flags are defined for a module, there must be a
     comment in configure.base explaining what the flags are for.

I agree with the spirit of your changes; I think we need to work out
exactly what situation we're trying to get to first, though.

Any comments on the above suggested policy?

-- 
Richard