1

A great deal of time is lost at the time of ./configure; especially when dependencies are missing and the subsequent calling thereof.

I've read many topics on this subject citing that caching the result of configure scripts for re-use with other configure scripts is error-prone due to stale results, things going out of sync, and that creating a common implementation for sharing results would be "very hard" [1].

I would like to note that I am aware that configure scripts already support caching but this is disabled by default [2].

If distributions already provide package managers which understand interdependencies and themselves already know what would be all of the common (or even most common) source dependencies, why is there no standard for some kind of configure cache available from the distro? One might be able to assume given certain conditions which can be evaluated by the package manager that many of these tests shouldn't need to be run at all. Or at the very least, not unless there is a failure during the configure.

Even though there are a number of other competing build systems, I find that configure is still the most prevalent by far. These scripts are shell-based, single-threaded, error-prone, often provide cryptic or no diagnostics, and are often extremely slow. It's not unusual for me to encounter a failure with a configure script or compilation due to a missing dependency that was not even part of configure.

Has this ever been addressed by any distro? For example, Gentoo does a tremendous amount of local compilation. Do they optimize any of this away?

I'm not looking for recommendations for build systems but rather a historical or cultural perspective on why things continue to rely so heavily on autoconf and configure for modern projects. This may very well fall within the bounds of opinion but I think that this is an extremely interesting topic which may have its fair share of facts based on build conventions, company policy, and greybeard customs.

A similar argument could made of mailing lists which are archaic compared to modern forms collaboration on the web but they are also simple and perform there function exactly the same now as they have always done with little to no change given its simplicity. Maybe autoconf follows a similar fate? (Disclaimer: I actually love mailing lists with any frustration being a result of poor support on the part of the mail client).

Improve this question
4
  • 2
    Remember, the whole world is not Linux. The same script may run on Solaris, the various BSDs, AIX, HP-UX, MacOS,... Even within Linux there are various packaging systems (rpm/yum, dpkg/apt, portage...). Typically the best way to validate that a build dependency is met on a system is to test it and see if it works. Painful, but portable. Commented Jul 28, 2018 at 15:45
  • As often as configuration and compilation can happen across Unix systems, it feels as though we've reached the point of "good enough" without much interest in further innovation. What we have certainly works. But it leaves me wondering why after so many years of autoconf that we don't have something universally better. Commented Jul 28, 2018 at 16:05
  • I think again we are mixing up the concept of Gnu and Linux. This whole issue is impossible to understand, until you know what Gnu and Linux are and are not. Commented Jul 28, 2018 at 16:50
  • One factor that may be affecting this, is that the GNU project wants all software to be possible to be built on as wide a selection of systems as possible. Commented Jul 28, 2018 at 16:52

2 Answers 2

Reset to default
1

Any answer will be at least a little bit speculation IMO, as what constitutes "innovation" differs from person to person (and whether it's a good thing!) Because autoconf is designed to be language- and architecture-agnostic for the most part, there's a lot of inertia keeping the desire to change low: you have to consider that some configure scripts are probably decades old by now, and people do not want to have to rewrite stuff that works.

Some of the restrictions that autoconf faces are architectural: For example, how can you use multithreading in a step that checks for multithreading? Will version 2.5 of libfoo work with a program that says it needs version 1.8? Other issues that you cite are often due to underspecification of dependencies: I've had many configure scripts that simply forget to list all of their direct dependencies. Lastly, autoconf seems to have a fairly limited number of maintainers, making it hard to make huge changes.

In some respects, package managers are where the innovation takes place. They can deal with concepts like different packages needing different versions of the same library, identify workarounds to dependencies that are no longer available, and (for source-compiling distros like Gentoo) provide patches to clean up configure scripts and source code so they work properly.

Improve this answer
4
  • As long as you bring up Gentoo, don't forget its use flags so that you can somewhat automate various ./configure options. I still recall the time I did a stage 1 from scratch (Gentoo had just come out) and I did all of X and the browser (Mozilla) and I forgot to add "+jpeg" to my use flags.... Commented Jul 28, 2018 at 17:39
  • A program that needs manual changes on configure options is badly maintained by it's author. My software compiles out of the box on all supported platforms. Commented Jul 28, 2018 at 18:02
  • @schily Normally, I agree that you shouldn't need to override the settings in a configure script. However, sometimes you want to use nonstandard locations and filename (usually for testing), and sometimes the script simply guesses wrong! I've had that happen a couple of times. Commented Jul 28, 2018 at 18:09
  • Such things do not belong into configure. You can do all this in my software using make command line macro definitions. Commented Jul 28, 2018 at 18:19
1

Autoconf of course caches the results and if you use it correctly, you rarely run configure.

My schilytools project (> 4000 source files, approx. 770000 lines of code) currently need approx. 800 autoconf tests. Running all tests takes 28 seconds on a 2.7 GHz Intel laptop, 2-3 hours on a HP-9000 pizza box from 1995, 4-6 hours on a Sun3/60 from 1996 and approx. a day on a Vax 11/780.

I still don't have to worry since the configure script is changed only approx. 5 times a year and rerunning configure takes ony 4 seconds on the Intel laptop as all the other tests are all cached. I of course have a make rule that causes configure to be run again only if the configure results are out of date.

Downstream people have a different view. They take the project as throw away packet and run a full blown configure 30 times a year and that takes 15 minutes a year.

I on the other side only have to wait 25 seconds a year....

So the problem is how the downstream people use the software.

Improve this answer
1
  • This is an interesting perspective and I enjoyed your citations of running the same script across multiple disparate systems. But this is answer is bias towards the experience of the developer or maintainer and isn't analogous to the user experience of setting up many packages and configuring them all from source for first time. This is why I mentioned caching to be handled by the distro rather than some user-level cache. Commented Jul 29, 2018 at 18:05

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.