Date: Mon, 3 Dec 2012 11:24:13 +0000 From: Alexey Dokuchaev <danfe@FreeBSD.org> To: Pietro Cerutti <gahr@FreeBSD.org> Cc: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org Subject: Re: svn commit: r308132 - head/audio/amrcoder Message-ID: <20121203112413.GA32882@FreeBSD.org> In-Reply-To: <20121203105616.GA86596@gahrfit.gahr.ch> References: <201212031034.qB3AYpkL004754@svn.freebsd.org> <20121203105040.GA30670@FreeBSD.org> <20121203105616.GA86596@gahrfit.gahr.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 03, 2012 at 11:56:16AM +0100, Pietro Cerutti wrote:
> On 2012-Dec-03, 10:50, Alexey Dokuchaev wrote:
> > I recall this is not the first similar fix. Is there reason not to uphold
> > ${CFLAGS} here instead?
>
> CFLAGS as set by the user are used:
>
> cc -O2 -pipe -fno-strict-aliasing -O3 -I/src -DVAD1 -std=gnu99
> -Qunused-arguments -fstack-protector -c decoder.c
-O3 (at least) is clearly bogus in this line.
> I see no reason, however, not to let the author supersede them with more
> appropriate flags.
Not too much software are written with clear mind about selected CFLAGS,
are well-tested and indeed the best (let say, vendor certified). These are
special cases that required cooperation between maintainer and the upstream
and had to dealt on per-port basis. We're not talking about these here.
Most often, however, folks just thow in -O3 or even -09 'cause they want
arbitrarily "the best" optimization and do not really care or know if doing
it improves anything for their program of not.
We should uphold our CFLAGS (that is, replace any unbridled optimization
options, not add to it) we're traditionally offering as sane and safe
defaults.
./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121203112413.GA32882>