Hi Willy, > On 11 Apr 2024, at 18:18, Willy Tarreau <[email protected]> wrote: > > Some distros simply found that stuffing their regular CFLAGS into > DEBUG_CFLAGS or CPU_CFLAGS does the trick most of the time. Others use > other combinations depending on the tricks they figured.
Good to know I wasn’t alone scratching my head about what came from where! > After this analysis, I figured that we needed to simplify all this, get > back to what is more natural to use or more commonly found, without > breaking everything for everyone. […] These are very nice improvements indeed, but I admit that if (at least partially) breaking backwards compatibility was the acceptable choice here, I’d have hoped to see something like cmake rather than a makefile refactoring. Actually, I’d thought a few times in the past about starting a discussion in that direction but figured it would be inconceivable. I don’t know how controversial it is, so the main two reasons I mention it are: - generally better tooling (and IDE support) out of the box: options/flags discovery and override specifically tends to be quite a bit simpler as the boilerplate and conventions are mostly handled by default - easier to parse final result: both of them look frankly awful, but the result of cmake setups is often a little easier to parse as it encourages a rather declarative style (can be done in gmake, but it is very much up to the maintainers to be extremely disciplined about it) Arguably, there’s the downside of requiring an extra tool everyone might not be deeply familiar with already, and cmake versions matter more than gmake ones so I would worry about compatibility for distros of the GCC 4 era, but it seemed to me like it’s reasonably proven and spread by now to consider. Tristan
