Rejuvenating Autoconf

Posted Oct 24, 2020 5:46 UTC (Sat) by ncm (guest, #165)
Parent article: Rejuvenating Autoconf

There is so much that could make autotools more tolerable.

All the C library feature test dreck can be stripped out. There is an ISO Standard for C implemented everywhere, and there is no reason to use a non-standard compiler and library, or test for them.

All the Bourne shell backward-compatibility and bug avoidance hacks can be stripped out. There is a Posix Standard for shells that is implemented everywhere a shell exists at all.

We don't need to support Eunice anymore.

Rejuvenating Autoconf

Posted Oct 24, 2020 7:47 UTC (Sat) by rurban (guest, #96594) [Link] (6 responses)

Even the most common compiler framework is violating the standard constantly. gcc 9 up to now broke it's stdlib, mostly for strings but also restrict so the features you want out are still needed. You need to test for the features you are using, or it will break. autoconf does this, and autoconf-archive is even better.

Rejuvenating Autoconf

Posted Oct 24, 2020 13:11 UTC (Sat) by smurf (subscriber, #17840) [Link] (5 responses)

No you don't. The feature is either there, which means that you can use it without testing for it, or it's not, which means that your build will go splat anyway.

So maybe you want to check for features in order to be helpful to the user. Fine, but you can do that with a simple test program or two. In more complicated cases you can create one file with flags and other constants (OK, one for each language that needs to digest this) and #include lines, and another with a list of libraries to link against. Done.

There's no longer a need for a program which uses an arcane ancient macro language to create a script which, when run, generates your Makefile from the side effect of mangling a Makefile.am to a Makefile.in during the first step, only to then use "make" to process the result. That's three levels of indirection and three sets of tools, which is at least two too many.

Once upon a time, when "make" was stupid (no conditionals, no functions …), the shell was randomly posixly incorrect, system include files had "sys/" in their path depending on OS subrelease and/or the phase of the moon, and other basic tools like "sed" couldn't be trusted with >254 character and/or non-ASCII lines … at that time the whole Autotools infrastructure may have made sense.

Today? not so much.

Rejuvenating Autoconf

Posted Oct 25, 2020 15:48 UTC (Sun) by tdz (subscriber, #58733) [Link] (3 responses)

> No you don't. The feature is either there, which means that you can use it without testing for it, or it's not, which means that your build will go splat anyway.

Please go and build your software with cygwin, where half of the math functions are there but broken. That might widen your perspective.

Rejuvenating Autoconf

Posted Oct 26, 2020 10:30 UTC (Mon) by intgr (subscriber, #39733) [Link] (1 responses)

That seems to suggest that Cygwin is broken, not the build system.

Maybe time would be better spent just fixing Cygwin, instead of subjecting all developers over the world to horribly complicated build-system-level work-arounds?

What you're describing is a manifestation of the platform problem https://lwn.net/Articles/443531/

> the platform problem comes about when developers view the platform they are developing for as fixed and immutable. These developers feel that the component they are working on specifically (a device driver, say) is the only part that they have any control over. If the kernel somehow makes their job harder, the only alternatives are to avoid or work around it. It is easy to see how such an attitude may come about, but the costs can be high.

Rejuvenating Autoconf

Posted Oct 26, 2020 10:48 UTC (Mon) by tdz (subscriber, #58733) [Link]

> Maybe time would be better spent just fixing Cygwin [...] ?

It's easier to fix the code than to roll-out the fix.

Rejuvenating Autoconf

Posted Oct 26, 2020 10:48 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Yeah, but what are you going to do with a broken (say) `cos` function? Code your own? Now, that doesn't mean put in hard errors for things[1], but you could at least add an `if cygwin; warn "This platform is not tested; proceed at your own risk"` warning to let people know. Once there's a suitable Cygwin release, you can version check it and suggest an upgrade.

[1]This lets those working on the known-broken platforms and new platforms not have to masquerade as something else to get past your arbitrary checkpoints (cf. basically every compiler emulating GCC and/or Clang at some point in their lifecycle to get past silly `#error "unknown compiler"` shenanigans).

Rejuvenating Autoconf

Posted Oct 26, 2020 19:28 UTC (Mon) by wahern (subscriber, #37304) [Link]

People seem to be confusing automake and autoconf in their autotools tirades. Autoconf can be used independently of automake and libtool, and this forthcoming release is just autoconf. IME, autoconf still works exceptionally well at writing feature tests. I've tried many alternatives, and even invented some of my own, but today I prefer using autoconf to generate config.h[1] and a simple make include (e.g. defaults.mk). I usually use plain POSIX make for my builds these days; GNU Make if I forget myself and decide to get unnecessarily fancy. Technically someone could build such a project of mine without invoking ./configure so long as they [re-]define'd all the necessary macros: CFLAGS, CPPFLAGS, SOFLAGS, LDLIBS, HAVE_FOO, etc when invoking make. Which, IMO, is how any [Unix] build system should work--in independent layers.

[1] Except I tweak output generation so that a macro is only define'd if not yet defined. For example, at the top of configure.ac,


# Redefine AH_TEMPLATE so that feature macros can be overridden from CPPFLAGS
m4_define([AH_TEMPLATE],
[AH_VERBATIM([$1],
	m4_text_wrap([$2 */], [   ], [/* ])[
@%:@ifndef ]_m4_expand([$1])[
@%:@undef ]_m4_expand([$1])[
@%:@endif])])

That makes it possible to override config.h from CPPFLAGS (or CFLAGS or w'ever). While autoconf is much better, IME, at being forward compatible than the alternatives, nothing is ever 100%. Sometimes a feature test will get things wrong, or perhaps a builder wants to manually mask some API (that invariably lacks a build switch). No matter what solution a project uses for its build, there's nothing worse than being forced to modify the build itself to quickly route around some trivial issue, regardless of whether it should or will end up as a proper patch.

Rejuvenating Autoconf

Posted Oct 24, 2020 11:10 UTC (Sat) by nilsmeyer (guest, #122604) [Link] (5 responses)

Isn't this work specifically to enable legacy users to continue to legacy use?

Rejuvenating Autoconf

Posted Oct 24, 2020 11:49 UTC (Sat) by willy (subscriber, #9762) [Link] (1 responses)

Yes, but the approach is wrong. Autotools detects which features are available on your platform. The right way is to have libiberty provide all the features needed on every platform.

Rejuvenating Autoconf

Posted Oct 25, 2020 10:18 UTC (Sun) by nix (subscriber, #2304) [Link]

I think that's more gnulib's job, these days. libiberty is literally just a shared toolchain support library. :)

Rejuvenating Autoconf

Posted Oct 25, 2020 8:10 UTC (Sun) by ncm (guest, #165) [Link] (2 responses)

Legacy users can use legacy autotools, legacy compilers, legacy languages, legacy OSes. None of that need bother us, in any sense. Leave them to it, and get on with things.

Rejuvenating Autoconf

Posted Oct 26, 2020 6:59 UTC (Mon) by nilsmeyer (guest, #122604) [Link]

It looks to me like this work is mostly funded to help support legacy users. I'm not really bothered by that either, if it helps make autotools better for everyone so much the better.

Rejuvenating Autoconf

Posted Oct 26, 2020 14:05 UTC (Mon) by Kamiccolo (subscriber, #95159) [Link]

Good luck dumping legacy backbone of modern computing.