On Fri, Aug 05, 2011 at 03:02:17PM +1000, Allan McRae wrote:
> On 05/08/11 09:35, Lukas Fleischer wrote:
> >In the course of a discussion with the xwax [1] developer, I was asked
> >the question why we would override CFLAGS (optimization levels, in
> >particular) if upstream already provides them. Given that there are in
> >fact loads of packages in our repositories that seem to follow this
> >practice (`grep -- '-O[0-9]' /var/abs/*/*/PKGBUILD` reveals some of
> >those), I'm forwarding this question to the ML.
> >
> >My own opinion is that we shouldn't patch anything here. While using the
> >same optimization flags for all packages might result in some kind of
> >consistency, one of our main guidelines - not to do any unnecessary
> >modifications - is kind of violated here. We should trust upstream
> >having chosen any explicit optimization flags with care (in some cases,
> >enforcing optimization flags might even lead to heavy performance
> >impacts - although this is unlikely to happen). I am aware that there
> >are some corner cases for sure, for which I'd say overriding CFLAGS is
> >okay. However, this shouldn't be common practice, imho.
> >
> >Opinions?
> >
>
> My opinion is that the upstream Makefile should add their CFLAGS and
> not override the ones provided by the environment unless there is a
> very good reason to do so. That way everybody gets the CFLAGS they
> want.
Agreed. Just appending CFLAGS will effectively result in overriding some
options, though. Quoting the gcc(1) manpage:
If you use multiple -O options, with or without level numbers, the
last such option is the one that is effective.
That is probably the reason some of us patch Makefiles to enforce our
optimization flags.
