How to Fix autoconf-style Configuration Probing

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.

▲

convolvatron 3 hours ago | parent | next [-]

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.

it was a always a bad plan.

	▲	nwmcsween 3 hours ago \| parent [-]
		So what do you check for? Assuming things works because __linux__ == glibc + Linux leads to all sorts of fun

▲

charcircuit 2 hours ago | parent | prev [-]

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.

	▲	coherentpony 2 hours ago \| parent [-]
		> Why is it important that the build host is portable? 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.