> But that doesn't mean that it was the right solution then, and it certainly is not the right solution now. I'm not saying it was the right solution, but the

> But that doesn't mean that it was the right solution then, and it certainly is not the right solution now. I'm not saying it was the right solution, but the essay makes a lot of claims beyond some straw man notion that autoconf is the right solution. Even in my critique I made it clear that autoconf is inevitably NOT the best solution. > There is no archtectural vision, no economy of style, no consistency and absolutely no symmetry or simplicity. There's a distinction between autoconf & the autoconf library. Autoconf itself has a comparatively simple design that was conceived and implemented largely over one summer by one engineer, who curated it through several subsequent iterations of embellishments. It's design was extended in to automake, etc. which lead to the whole GNU build system. The automake library on the other hand is largely a Bazaar of contribution of work arounds from developers, with some modest efforts at curation that emerged over time, rather than being conceived from the get go. > That is of course better than doing it all the time, but it is still going to stink. It still might stink, but it is hardly the most important problem most people deal with, and the whole process functions well enough in the end, so the people with the expertise to make a better solution have other more pressing problems instead.