Hi Tristan, On Fri, Apr 12, 2024 at 07:38:18AM +0000, Tristan wrote: > Hi Willy, > > > On 11 Apr 2024, at 18:18, Willy Tarreau <w...@1wt.eu> 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!
Definitely. > > 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, It should almost not break it otherwise it will indicate what changed and how to proceed. > I'd have hoped to see something like cmake rather than a makefile > refactoring. That's orthogonal. cmake is an alternative to autoconf, not to make, you still run "make -j$(nproc)" once cmake is done. And such mechanisms are really really a pain to deal with, at every stage (development and user). They can be justified for ultra-complex projects but quite frankly, having to imagine not being able to flip an option without rebuilding everything, not having something as simple as "V=1" to re-run the failed file and see exactly what was tried, having to fight against the config generator all the time etc is really a no-go for me. I even remember having stopped using OpenCV long ago when it switched from autoconf to cmake because it turned something complicated to something out of control that would no longer ever build outside of the authors' environment. We could say whatever, like they did it wrong or anything else, but the fact is I'm not going to impose a similar pain to our users. In our case, we only need to set a list of files to be built, and pass a few -I/-L/-l while leaving the final choice to the user. > 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) The problem with tools like cmake is not to parse the output when it works but to figure how to force it to accept that *you* are the one who knows when it decides it will not do what you want. While a makefile can trivially be overridden or even fixed, good luck for guessing all the magic names of cmake variables that are missing and that may help you. I really do understand why some super complex projects involving git submodules and stuff like this would go in that direction, but otherwise it's just asking for trouble with little to no benefit. > 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. It's not even a matter of compatibility with any gcc version, rather a compatibility with what developers are able to write and what users want to do if that was not initially imagined by the developers. Have you read already about all the horrors faced by users trying to use distcc or ccache with cmake, often having to run sed over their cmake files ? Some time ago, cmake even implemented yet another magic variable specifically to make this less painful. And cross-compilation is yet another entire topic. All of this just ends up in a situation where the build system becomes an entire project on its own, just for the sake of passing 6 variables to make in the end :-/ In the case of a regular makefile at least, 100% of the variables you may have to use are present in the makefile, you don't need to resort to random guesses by copy-pasting from stackoverflow and see if they improve your experience. Long ago I thought that we could possibly support a config file to carry options between versions, a bit like the .config in the Linux kernel. Because one of the difficulties that those using autoconf/cmake is to figure in what form to store a working setup. In practice there's no magic solution and you end up saving the whole command line, just like we're doing right now. And I thought that may be some users (particularly those pulling the dev version often) could like to have a .config being loaded with their presets (CC, CFLAGS, USE_xxx, etc), but I must confess I don't see a difference between this and having a one-line script that contains all these settings, or a more elaborated script that deals with your various preferences. We have quite few options so I don't see much value in this, but if others do, that's something I could easily understand. And the benefit of a .config is that it doesn't remove the ability to forcefully override certain settings from the command line without having to change that file. Willy
