Comment by Tobu | Hacker News Reader

Comment by Tobu | Hacker News Reader

Parent Full thread

One thing that improves reliability is in fact to get rid of the configuration step. Not just the workarounds for broken shells or old Solaris/HP-UX versions with anemic libcs, but the principle of disabling some features or switching to alternative implementations when something isn't found. It just creates new code paths and combinatorial complexity, probably broken because the developer's environment will never trigger them. Distro packagers already prefer hard fails to know when they are missing a dependency.

To compensate, the replacement just needs to offer better facilities for triggering installs of the missing dependencies. That's basically the path taken by modern languages (Go, Python, Ruby, Node… gnome's jh_build is part of the same trend): they have tools to fetch source dependencies from the network, to install in custom prefixes that don't require root, to create isolated prefixes so that multiple versions can be installed in parallel, to freeze known-good versions of the dependency graph.

But those little knobs so you can build your own customised version with decals and your own red spoiler? No one will miss them.

Yes, there are lots of little knobs used by those wacky Gentoo folks, and those dumb old shells on Unix of decades past. My ideal replacement would get rid of those checks and assume you have a working POSIX shell and C89.

However, there are also optional dependencies. SoX can use FFTW to make spectrograms, but it's optional. You can use x264 from ffmpeg but it's not necessary. Emacs will build with GTK 2 support, GTK 3 support, or neither; and it will use whatever PNG/JPEG/XML/etc libraries happen to be installed but doesn't care if they're not present. GCC will use Graphite whet available. A few programs will happily play audio through libao or Core Audio or ALSA. There's combinatorial complexity there in theory, but it's not hard to isolate optional dependencies in practice, most of the time.

And suppose you want to use some feature available on new Linux kernels. It's just easier to write an autoconf test rather than try to come up with some convoluted preprocessor test.

There are also important knobs to tune: look at LibGMP, ATLAS, or FFTW for examples. Old PowerPC Macs could run 64-bit code if you asked but ran 32-bit by default, so you'd compile GMP for 64-bit and get a huge performance boost.

And some options are only useful to developers, like enabling -Werror (which should never be enabled by default in a source release). The configuration step bakes these options into the makefile so you can still just type "make".

You have a good point about hard failing when dependencies aren't present, and the configuration step allows you to fail early and provide an intelligent error message.

I'm not convinced that eliminating a configuration step improves reliability. Just think of how dirt-common autoconf scripts are, in spite of how much of a pain autoconf is to learn.

A short set of config options works well for most things though, rather than autodetect. After all most people will be packaging and need to control exact dependencies. I dont mind reading through a config file to tweak these settings.

A lot of those knobs are actually pretty useful, especially when there are competing implementations of a standardized interface that have different strengths. As an example: In scientific computing this often means choosing a particular BLAS or MPI implementation when compiling, sometimes based on the data in a particular run.

Not saying autoconf is awesome (I curse it on a regular basis), but the configure step itself is worth keeping around.

Reply on news.ycombinator.com