Date: Wed, 13 Feb 2013 16:40:27 +0000 From: "b.f." <bf1783@googlemail.com> To: mexas@bristol.ac.uk, sgk@troutmask.apl.washington.edu, freebsd-ports@freebsd.org Subject: Re: 7+ days of dogfood Message-ID: <CAGFTUwNKNUeKA70mjZj%2BjZR3QhmD%2ByUdu2=KMaM3rTZ4gS1n7g@mail.gmail.com> In-Reply-To: <201302131105.r1DB5L1V094976@mech-cluster241.men.bris.ac.uk> References: <20130213033933.GA89757@troutmask.apl.washington.edu> <201302131105.r1DB5L1V094976@mech-cluster241.men.bris.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/13/13, Anton Shterenlikht <mexas@bristol.ac.uk> wrote:
> From sgk@troutmask.apl.washington.edu Wed Feb 13 03:40:53 2013
>
> On Wed, Feb 13, 2013 at 02:15:08AM +0000, b.f. wrote:
> > On 2/13/13, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
> > > On Wed, Feb 13, 2013 at 12:18:29AM +0000, b.f. wrote:
> > >> ># cat /etc/make.conf|grep FFLAGS
> > >> >FFLAGS = -O2 -pipe -march=native -mtune=native
> > >>
> > >> Please do _not_ assign flags unconditionally in make.conf.
> > >
> > > FFLAGS is for compiling Fortran. I'm one of the people who
> > > has spent years working/patching gfortran. I think I might
> > > have a better understanding of what options to use with
> > > gfortran than most people.
> > >
> >
> > I know you have, but you are giving advice that is liable to be abused
> > by those who are less experienced. The flags you are adding are not
> > the problem -- it's the way that you are adding them -- specifically,
> > the assignment in the first line of your snippet, if it's applied
> > unconditionally. You should either be appending all of them, or
> > assigning them conditionally, so that they are sure to be assigned
> > only once, or -- preferably -- using another makefile that can't be
> > re-read multiple times during a build (ports/Mk/bsd.port.mk
> > automatically includes several makefiles that can be used for this
> > purpose, if you are building a port). You have been lucky not to trip
> > over this: every couple of months for the last several years I have
> > had to debug errors reported by users that arise from this problem. It
> > is more common with CFLAGS and CXXFLAGS but it can happen with FFLAGS,
> > too.
>
> Try 'find /usr/ports -name Makefile -maxdepth 3 | xargs grep FFLAGS'
> Then go read about the options chosen by the various port maintainers.
> I specifically set FFLAGS to avoid the questionable options set in
> the ports. If -malign-double appears in a port, it should probably
> be marked as broken. If a port uses -fdefault-real-8, it should probably
> be marked as broken. If a port uses -ffast-math, it may have issues that
> are extremely difficult to debug.
>
> (I removed freebsd-current@ and added cc to ports@)
>
> Oi vey. I see, it is complicated.
> So on the one hand some options are
> risky or just wrong and must not be used.
> On the other there is a large number of ports,
> which might not even build if this is implemented,
> and convincing upstream that they are wrong
> is never easy.
>
> Is there a middle ground?
> What about appending the suggested options
> to FFLAGS in ports/MK/bsd.port.mk?
> Or will it make debugging ports with "questionable"
> options even harder?
By all means, adjust our conservative default flags if you want to
improve the performance of some ports or other software -- only be
sure to test the results. Dr. Kargl has given you some good
candidates. But I'd advise you to add to the flags once at the start
of a build, and to deal with flag changes in a port or other piece of
software that you think are unnecessary and problematic by patching
the software itself. (If the software uses gmake or adds problematic
flags and then uses them before it invokes make(1) again you won't be
able to deal with them in make.conf, anyway.) It's probably best to
use a makefile that was intended for this purpose, like
${PORTSDIR}/Mk/bsd.local.mk. (Or, If you still prefer make.conf, you
could make the flag alterations there, but conditionally -- you could
test .CURDIR, for example, to prevent your changes from being
reapplied if you have descended into a work directory. But using
another makefile would probably be better.)
b.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGFTUwNKNUeKA70mjZj%2BjZR3QhmD%2ByUdu2=KMaM3rTZ4gS1n7g>