Re: Packages not honouring CFLAGS

[Pierre Pronchery <khorben%defora.org@localhost>]

			Hi tech-pkg@,

On 08/08/2015 20:15, David Holland wrote:
> 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.

It looks like it is set here indeed:
mk/bsd.pkg.mk
159 ALL_ENV+=       CFLAGS=${CFLAGS:M*:Q}

Some packages are not affected by the environment - including mine
(deforaos-*). Those which do are apparently fine already; I think this
is how GNU autoconf catches the relevant flags for instance.

As a software author, I do not like when the build process is silently
affected by the environment. This has bitten me a lot in the past,
particularly when working on Debian packages: they do (did?) not filter
the environment in any way while building, with many packages shipping
impossible to build without the same (undocumented) environment as the
maintainer - or worse, building differently.

This is why the build system of my DeforaOS stack does not accept any
default value from the environment, but allows them to be overridden
explicitly.

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

Ok.

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

Yes, this is what I am currently doing. It works well for CFLAGS so far.
I suspect it will be more difficult for LDFLAGS, but the work on CFLAGS
should help determining which packages are affected.

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

If a package expects to be built by, say, MSVC and uses flags specific
for it, then a wrapper for pkgsrc has to understand these flags to
remove (or convert) them. Since we support many platform/compiler
combinations, each wrapper should then (in theory) understand each of
those combinations, for every underlying tool ($CC, $LD, $AR...).

In practice most OSS projects either expect GNU/Linux/gcc or somehow
detect or tolerate other platforms, so we do not have this problem. But
if there was much more diversity we would certainly need a way to remove
those platform-specific CFLAGS and LDFLAGS before entering any wrapper
(this is what I meant by "proper support").

HTH,
-- 
khorben