Subject: Re: fluxbox and -funroll-loops
To: Johnny C. Lam <jlam@NetBSD.org>
From: David Brownlee <abs@NetBSD.org>
Date: 09/01/2004 09:57:39
On Wed, 1 Sep 2004, Johnny C. Lam wrote:
> On Tue, Aug 31, 2004 at 10:30:12AM -0400, Jan Schaumann wrote:
>> I don't think that's necessary. I don't believe that our packages
>> should try to compile every package with every possible CFLAG and then
>> add the necessary transforms just in case the user chooses to add that
>> CFLAG manually.
>> Are we going to add
>> BUILDLINK_TRANSFORM+= rm:-illegal-flag
>> on the off chance that the user adds "-illegal-flag" to his/her CFLAGS?
> Basically, I can't think of a compelling reason not to do this, since
> it's so easy to do. I think it's worthwhile because then we're not
> basically restricting users to setting CFLAGS in /etc/mk.conf to some
> lowest common denominator of compiler optimization options across all
> packages he might wish to build. We don't have to go out of our way
> to hunt down these bad option/package pairs, but when we notice them,
> it's rather easy to just fix it.
> We could probably do a better job of organizing some of this material.
> Right now, we stick all of this stuff in the package Makefiles
> themselves, but this makes those Makefiles somewhat lengthy and harder
> to understand. We also document some of it in pkgsrc/doc/HACKS, but
> mostly this file is just duplicate information to what's in the package
> Makefile. Maybe we should gather all of these workarounds into Makefile
> fragments and separate them out of the main package Makefiles, e.g.
> wm/fluxbox/hacks.mk, and we could have bsd.pkg.mk include hacks.mk if
> it exists. It becomes somewhat clearer which packages need workarounds
> for build problems, i.e. "find /usr/pkgsrc -name hacks.mk". If we
> choose to do this, then I'll point out that this is a fairly easy
> project for someone with a bit of spare time.
We have prior art for this:
# Postgresql explicitly forbids any use of -ffast-math
(I'm very much in favour of this)
David/absolute -- www.NetBSD.org: No hype required --