[arch-general] Enforcing CFLAGS in PKGBUILDs

older
Re: [arch-general] Plasma-desktop...

Lukas Fleischer

4 Aug 2011 4 Aug '11

11:35 p.m.

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? Link to the original thread (for clarification) [2]. [1] http://www.xwax.co.uk/ [2] http://sourceforge.net/mailarchive/forum.php?thread_name=1108042258340.847%40localhost&forum_name=xwax-devel

Show replies by date

Allan McRae

5 Aug 5 Aug

5:02 a.m.

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. Allan

Lukas Fleischer

11:15 a.m.

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.

Ray Rashif

7:23 a.m.

On 5 August 2011 07:35, Lukas Fleischer wrote:

...

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?

I have wondered about this before. Upstream developers should include in their code/buildsystem proper conditional CFLAGS, i.e append to system CFLAGS, override _only_ what they want to override, and don't append anything already part of the system CFLAGS. For eg. some developers like to enforce -O3, so they should first get the system CFLAGS and override it's -O*, if any. But in general, I agree. We shouldn't enforce anything either unless we're trying to fix something. The ardour PKGBUILD does this [1], maybe it shouldn't, but I assume the -O3 becomes redundant when we pass system CFLAGS to the build as a configuration flag. [1] http://projects.archlinux.org/svntogit/packages.git/tree/ardour/trunk/PKGBUI... -- GPG/PGP ID: 8AADBB10

Jan de Groot

8:54 a.m.

On Fri, 2011-08-05 at 15:23 +0800, Ray Rashif wrote:

...

For eg. some developers like to enforce -O3, so they should first get the system CFLAGS and override it's -O*, if any.

But in general, I agree. We shouldn't enforce anything either unless we're trying to fix something. The ardour PKGBUILD does this [1], maybe it shouldn't, but I assume the -O3 becomes redundant when we pass system CFLAGS to the build as a configuration flag.

[1] http://projects.archlinux.org/svntogit/packages.git/tree/ardour/trunk/PKGBUI...

Looking at ardour, I see it's also patched to support gcc 4.6. Now let's say something about -O3: -O3 optimization can be very bad and the results are extremely dependent on the compiler version. Something that works optimal with gcc 4.4 and -O3 can break completely with gcc 4.6 and -O2. Just adding -O3 to CFLAGS without knowing which compiler is used is plain stupid. Check this blog for example: http://glandium.org/blog/?p=1975 There someone from Mozilla claims they're finally able to build with O3 +PGO with GCC 4.5. This was at the time we were already doing O2+PGO from our PKGBUILD with 4.5 and now 4.6.

Lukas Fleischer

11:30 a.m.

On Fri, Aug 05, 2011 at 10:54:41AM +0200, Jan de Groot wrote:

...

On Fri, 2011-08-05 at 15:23 +0800, Ray Rashif wrote:

...
For eg. some developers like to enforce -O3, so they should first get the system CFLAGS and override it's -O*, if any.

But in general, I agree. We shouldn't enforce anything either unless we're trying to fix something. The ardour PKGBUILD does this [1], maybe it shouldn't, but I assume the -O3 becomes redundant when we pass system CFLAGS to the build as a configuration flag.

[1] http://projects.archlinux.org/svntogit/packages.git/tree/ardour/trunk/PKGBUI...

Looking at ardour, I see it's also patched to support gcc 4.6. Now let's say something about -O3: -O3 optimization can be very bad and the results are extremely dependent on the compiler version. Something that works optimal with gcc 4.4 and -O3 can break completely with gcc 4.6 and -O2.

You should file a bug report if it does. Given the number of PKGBUILDs that patch optimization levels, I would also say that this is only true for a minority of cases.

...

Just adding -O3 to CFLAGS without knowing which compiler is used is plain stupid. Check this blog for example: http://glandium.org/blog/?p=1975 There someone from Mozilla claims they're finally able to build with O3 +PGO with GCC 4.5. This was at the time we were already doing O2+PGO from our PKGBUILD with 4.5 and now 4.6.

Ray Rashif

2:53 p.m.

On 5 August 2011 16:54, Jan de Groot wrote:

...

On Fri, 2011-08-05 at 15:23 +0800, Ray Rashif wrote:

...
For eg. some developers like to enforce -O3, so they should first get the system CFLAGS and override it's -O*, if any.

But in general, I agree. We shouldn't enforce anything either unless we're trying to fix something. The ardour PKGBUILD does this [1], maybe it shouldn't, but I assume the -O3 becomes redundant when we pass system CFLAGS to the build as a configuration flag.

[1] http://projects.archlinux.org/svntogit/packages.git/tree/ardour/trunk/PKGBUI...

Looking at ardour, I see it's also patched to support gcc 4.6. Now let's say something about -O3: -O3 optimization can be very bad and the results are extremely dependent on the compiler version. Something that works optimal with gcc 4.4 and -O3 can break completely with gcc 4.6 and -O2. Just adding -O3 to CFLAGS without knowing which compiler is used is plain stupid. Check this blog for example: http://glandium.org/blog/?p=1975 There someone from Mozilla claims they're finally able to build with O3 +PGO with GCC 4.5. This was at the time we were already doing O2+PGO from our PKGBUILD with 4.5 and now 4.6.

Good that you bring this up - I was totally unaware of this correlation. -- GPG/PGP ID: 8AADBB10

Lukas Fleischer

11:24 a.m.

On Fri, Aug 05, 2011 at 03:23:44PM +0800, Ray Rashif wrote:

...

On 5 August 2011 07:35, Lukas Fleischer wrote:

...
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?

I have wondered about this before. Upstream developers should include in their code/buildsystem proper conditional CFLAGS, i.e append to system CFLAGS, override _only_ what they want to override, and don't append anything already part of the system CFLAGS.

For eg. some developers like to enforce -O3, so they should first get the system CFLAGS and override it's -O*, if any.

Well, just appending their own flags (which is what most Makefiles do) is no problem here as only the last "-O" option will matter (check my reply to Allan).

...

But in general, I agree. We shouldn't enforce anything either unless we're trying to fix something.

+1.

...

The ardour PKGBUILD does this [1], maybe it shouldn't, but I assume the -O3 becomes redundant when we pass system CFLAGS to the build as a configuration flag.

Yeah, I agree that patching is okay if it's necessary in order to build a package (or in order not to break anything). That's what I mentioned above.

Bernardo Barros

3:18 p.m.

If I may: I think if they (devs) work with that particular program, they should know better if a -O3 optimization is more adequate or not then a -O2 or whatever, more then the packager -- that is not so deeply involved with the project anyway.

4654

Age (days ago)

4655

Last active (days ago)

List overview

Download

8 comments

5 participants

participants (5)

Allan McRae
Bernardo Barros
Jan de Groot
Lukas Fleischer
Ray Rashif