Hello. > 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.
This sentence seems a bit unfair. The new implementation has come with new regression tests, and does not increase the source complexity. > 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. I will investigate, but without much hope. The difference is probably caused by things like conflicting CFLAGS on the command line or in the environment, from debian/rules or dpkg-buildpackage, for ./configure or make, possibly kept by ./configure for make despite a now conflicting environment… This mess is probably one of the reasons why DEB_CFLAGS_MAINT_APPEND was introduced and CFLAGS+= deprecated in both the environment and debian/rules. Moreover, I cannot connect to buildds either. The fact that the previous lazy evaluation mechanism, in which the $(evals VAR=$(VAR)) trick is already present, did what you expect in some contexts does not make CFLAGS+= a supported interface, and your code could break in other contexts. Replacing CFLAGS+= foo with DEB_CFLAGS_MAINT_APPEND := foo in the broken packages seems more fruitful to me, and I would prefer to help with that. That would most probably fix this bug, does not hurt if the optimization is reverted, and will actively help if dpkg-buildpackage ever becomes the main entry point for package builds.
