> So couldn't we just use the build system to do the probing?
Yes, indeed. And I do exactly that with a Bernstein redo build system. Daniel J. Bernstein had this idea decades ago, with the has/try system evident in publicfile back in in 1999, for example. Converted to redo, which Bernstein never did, it looks like this:
before pretty much everything else, which invokes the config/all.do at that level, which in turn builds all of the headers via their has*.h.do files and using the try*.cpp files. config/cxx.do builds the name of the compiler, as picked up by ./compile at the top level. config/cxxflags.do builds its flags.
redo handles rebuilding everything as necessary, including all of the programs that include the feature test headers, if a has*.h.do file changes, a try*.cpp file changes, the compiler/linker options change, or the ./compile and ./link scripts change. It's even possible, although I don't do it, once ${cxx} has been determined in cxx.do, to do a
redo-ifchange -- "${cxx}"
and make the whole thing sensitive to the actual compiler changing. I don't do it in the nosh build because it's not worth being that sensitive to the tooling. I actually do do it in the djbwares build (which collects publicfile and various other Bernstein softwares under a single umbrella).
So yes, using the very same build system that is building the software to build the feature probes is an idea that is at least a quarter century old, and Daniel J. Bernstein was almost there. Xe just never published an actual redo that could do what xe called 'honest prerequisites'. Xe got as far as ./choose in a Makefile, though.
Yeah maybe it's less visible nowadays, but in the past the world was not just Linux and FreeBSD. There were many commercial Unixes which differed from each other and from Linux. And to be portable to such systems you needed to check everything. So autoconf was a crucial tool, not just a fancy noop.
I lived in that world, sunos, solaris, unicos, hpux, aix, irix, ultrix. I always found it preferable to have Os and even compiler specific includes for a whatever definitions needs to be different. and I certainly wasn't interested in having a rewrite pass on the makefiles. but it worked well enough when I dug up something on archie.
and then they wrapped it another layer of translation, and then another and I think more. and things started breaking because I needed the right version of autotools, and at some point I started just running "cc *.c -I. -o foo" before even starting to try to use configure, and it usually worked and saved me a lot of screwing around.
its certainly settled down some, but only because everything is really linux. but still we're here more than 30 years later checking for socklen_t.
Why is it important that the build host is portable? Why not choose a single platform for your CI and build for all of your targets on those using a compatibility library to cover up differences.
Yes, indeed. And I do exactly that with a Bernstein redo build system. Daniel J. Bernstein had this idea decades ago, with the has/try system evident in publicfile back in in 1999, for example. Converted to redo, which Bernstein never did, it looks like this:
* https://github.com/jdebp/nosh/tree/trunk/source/config
Notice that all.do at the top level does
before pretty much everything else, which invokes the config/all.do at that level, which in turn builds all of the headers via their has*.h.do files and using the try*.cpp files. config/cxx.do builds the name of the compiler, as picked up by ./compile at the top level. config/cxxflags.do builds its flags.redo handles rebuilding everything as necessary, including all of the programs that include the feature test headers, if a has*.h.do file changes, a try*.cpp file changes, the compiler/linker options change, or the ./compile and ./link scripts change. It's even possible, although I don't do it, once ${cxx} has been determined in cxx.do, to do a
and make the whole thing sensitive to the actual compiler changing. I don't do it in the nosh build because it's not worth being that sensitive to the tooling. I actually do do it in the djbwares build (which collects publicfile and various other Bernstein softwares under a single umbrella).So yes, using the very same build system that is building the software to build the feature probes is an idea that is at least a quarter century old, and Daniel J. Bernstein was almost there. Xe just never published an actual redo that could do what xe called 'honest prerequisites'. Xe got as far as ./choose in a Makefile, though.
* http://jdebp.info./FGA/introduction-to-redo.html
* https://cr.yp.to/redo/honest-script.html
* https://salsa.debian.org/debian/publicfile/-/blob/master/Mak...
and then they wrapped it another layer of translation, and then another and I think more. and things started breaking because I needed the right version of autotools, and at some point I started just running "cc *.c -I. -o foo" before even starting to try to use configure, and it usually worked and saved me a lot of screwing around.
its certainly settled down some, but only because everything is really linux. but still we're here more than 30 years later checking for socklen_t.
it was a always a bad plan.
The person you’re replying to did not say the build host has to be portable. They said that the software configuration script needed to be portable:
> And [for `configure`] to be portable to such systems you needed to check everything.
Edit:
> Why not choose a single platform for your CI and build for all of your targets on those using a compatibility library to cover up differences.
You can. Nothing precludes you from doing this. But there are situations where you control neither the build environment nor the install environment.