Am Mittwoch, dem 03.04.2024 um 18:02 +0200 schrieb Michael Matz: > Hello, > > On Wed, 3 Apr 2024, Martin Uecker wrote: > > > The backdoor was hidden in a complicated autoconf script... > > Which itself had multiple layers and could just as well have been a > complicated cmake function.
Don't me wrong, cmake is no way better. Another problem was actually hidden in a cmake test in upstream git in plain sight: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00;hp=af071ef7702debef4f1d324616a0137a5001c14c > > > > (And, FWIW, testing for features isn't "complex". And have you looked at > > > other build systems? I have, and none of them are less complex, just > > > opaque in different ways from make+autotools). > > > > I ask a very specific question: To what extend is testing > > for features instead of semantic versions and/or supported > > standards still necessary? > > I can't answer this with absolute certainty, but points to consider: the > semantic versions need to be maintained just as well, in some magic way. It would certainly need to be maintained just like now autoconf configuration needs to be maintained. > Because ultimately software depend on features of dependencies not on > arbitrary numbers given to them. The numbers encode these features, in > the best case, when there are no errors. So, no, version numbers are not > a replacement for feature tests, they are a proxy. One that is manually > maintained, and hence prone to errors. Tests are also prone to errors and - as the example above shows - also very fragile and susceptible to manipulation. > > Now, supported standards: which one? ;-) Or more in earnest: while on > this mailing list here we could chose a certain set, POSIX, some > languages, Windows, MacOS (versions so-and-so). What about other > software relying on other 3rdparty feature providers (libraries or system > services)? Without standards? > > So, without absolute certainty, but with a little bit of it: yes, feature > tests are required in general. That doesn't mean that we could not > do away with quite some of them for (e.g.) GCC, those that hold true on > any platform we support. But we can't get rid of the infrastructure for > that, and can't get rid of certain classes of tests. > > > This seems like a problematic approach that may have been necessary > > decades ago, but it seems it may be time to move on. > > I don't see that. Many aspects of systems remain non-standardized. This is just part of the problem. Martin > > > Ciao, > Michael.
