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.