Hi!

On Thu, 2024-07-25 at 10:19:28 +0300, Michael Tokarev wrote:
> Package: dpkg-dev
> Version: 1.22.8
> Severity: important

> It seems like constructs like
> 
>   include /usr/share/dpkg/buildflags.mk
>   CFLAGS += -DFOO
>   LDFLAGS += -lbar
> 
> etc somehow stopped working on buildds since dpkg 1.22.8,
> although I can't reproduce it locally no matter how I try.
> 
> An example is samba package which uses this construct in
> a few places, and later uses the variables like this:
> 
>   CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" ./configure ...
> 
> No matter what I append to these variables, the resulting
> value does not change.
> 
> I can only guess this is due to dpkg_lazy_eval which resets
> values of each variable (it has `eval VAR=VAL` inside), but
> the thing is that I can't reproduce it locally.  Something
> might be different on a buildd.
> 
> Yes, I can switch to using DEB_LDFLAGS_MAINT_APPEND etc,
> but it requires quite some rearrangements/reordering of
> d/rules, and it doesn't tell me why current way, which
> used to work before, broke now.
> 
> This issue potentially can affect multiple packages in an
> unexpected way, because CFLAGS+=foo definitely used to
> work before.
> 
> And no, 1.22.9 upload does not fix the issue.

Hmm, at this point I'm starting to ponder whether to revert the
optimization commit for the Makefile fragment files, because this
is starting to feel like too much breakage, and then the fragment
code is becoming too hard to debug, or even test.

Although, my ideal path forward has been for a long time to try to
make these files completely unnecessary, and instead make
dpkg-buildpackage be able to set any of these flags, which would be
way cheaper as it has already computed most if not all of those, and
avoid reparsing files, etc. But that partially depends on making
dpkg-buildpackage the only supported entry point. I'll try to bring
that up on the list in a bit.

I've not yet looked into it, Nicolas if you can have a look please,
otherwise I might do the revert and another upload later today or so.

Thanks,
Guillem

Reply via email to