Re: Packages not honouring CFLAGS

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Fri, Aug 07, 2015 at 04:48:12PM +0200, Pierre Pronchery wrote:
 > - for those using regular Makefiles it should ideally be a matter of
 >   MAKE_FLAGS+=CFLAGS=${CFLAGS:Q} but I expect many headaches there :(

Put it in MAKE_ENV (and actually, I think it already is) otherwise
overriding any settings the package itself attempts to make is bound
to break things. Also, in the environment it's more likely to be
inherited by submakes.

The problem is: standard practice for a long, long time among people
who know what they're doing has been to always explicitly set CFLAGS
(as well as LDFLAGS, CC, and so on) to avoid accidentally using a
default value built into make. Because, historically, vendor makes
shipped with all kinds of unbelievable crap defaults, and failing to
discard them was sure to get you build failures on buggix systems.

Every single such package will need to be patched. Some have been;
most haven't.

If you want to make a significant dent in this you need (a) a way to
determine if CFLAGS and LDFLAGS were actually honored for any given
build product (PIE will probably do), (b) a way to make sure the
output of all package builds conforms (this probably requires a custom
check pass to find/test all executables), (c) run an ongoing bulk
build series dedicated to the proposition, and (d) start slogging.

 > Using wrappers does make a lot of sense, since quite a few packages may
 > well end up with contradictory flags - and this is harder to fix than
 > just adding CFLAGS.

...this is more likely if you inject more CFLAGS with the wrappers, I
would think.

 > But even then, paving the way for proper
 > CFLAGS/LDFLAGS support should also relieve the wrappers from dealing
 > with situations with flags mixing compilers, platforms or whatnot.

That is unlikely. I'm not sure what you think constitutes 'proper'
CFLAGS/LDFLAGS support.

-- 
David A. Holland
dholland%netbsd.org@localhost