[Build-common-hackers] Bug#523642: Bug#523642: Bug#523642: overrides CFLAGS too agressively

[Robert Millan]

On Sat, Apr 11, 2009 at 10:06:45PM +0200, Jonas Smedegaard wrote:
> On Sat, Apr 11, 2009 at 07:07:07PM +0200, Robert Millan wrote:
> >On Sat, Apr 11, 2009 at 06:13:58PM +0200, Jonas Smedegaard wrote:
> >> 
> >> I do not say that CDBS is correct or not in its current behaviour, 
> >> just that it has a well defined vurrent behaviour that users rely on 
> >> (whether or not they are aware of it).
> >> 
> >> I have tagged this as wontfix for that reason.  Please note that even 
> >> if this means I do not expect this to change (or at least not soon - 
> >> it is possible to change when we decide to bump ABI at some point, if 
> >> ever), I am still interested in discussing it!
> >
> >Why not use an environment variable then?
> 
> Like you quoted right above: Because CDBS is in active use with current 
> behaviour.
> 
> Does that somehow not make sense?

What I mean is, why not use an environment variable such that when defined,
and only when it is defined, it overrides current behaviour?

E.g. DISABLE_MAKE_VARIABLE_OVERRIDE := yes

This doesn't break existing use.

Another option could be that when CFLAGS is unset (rather than empty), CDBS
detects this and doesn't pass anything as override.  This allows user to
explicitly set CFLAGS in DEB_MAKE_ENVVARS, or not at all.

> >> Could you perhaps provide some good examples of upstream software 
> >> needing custom CFLAGS that is cumbersome to work around using CDBS?
> >
> >Yeah, Linux modules.  Or plugins in general for all sort of programs.  
> >They're usually very picky when it comes to CFLAGS.
> 
> I understand that they are picky about CFLAGS, but can't their CFLAGS be 
> re-applied when using CDBS?

Because I would have to duplicate a really long set of flag declaration,
which isn't even consistent across architectures, and doesn't even depend
on the upstream makefile but rather on the Linux ones (Linux modules are
usually built using centralized makefiles), and therefore can change
depending on which Linux version are we building against.

I'll rather maintain a local version of makefile-vars.mk in debian/ than
having to do that.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."