[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Autoconf and apt

From: Braden McDaniel
Subject: Re: Autoconf and apt
Date: Tue, 19 Aug 2008 19:24:38 -0400
User-agent: Thunderbird (Macintosh/20080707)

Bob Friesenhahn wrote:
On Tue, 19 Aug 2008, Allan Clark wrote:

I therefore urge you to reconsider using existing resources for more common
cases rather than serial dependencies on new, undiscovered data and 100%
coverage which might be too difficult to reach.

You are optimizing the special case where dependencies are to be installed from "packages" but this package is configured via a configure script. Most users who install packages install "packages" prepared by someone else and never run a configure script. They might not even have a working compiler installed on their system.

Perhaps what is needed is a new "--list-dependencies" option which prints prepared text listing the possible dependencies of this package. It is not clear how well this will work though since many Linux developers do not know the dependencies of their own software. They just expect these dependencies to be automatically available as part of the Linux distribution.

And the name of a binary package can diverge from the name of the upstream source tarball. And a source package can spawn multiple binary packages, with likely variation between different binary distributions. And development headers might be packaged separately--under a name whose convention can vary across distributions.

configure is really a horrible place to do real dependency tracking; primarily because trying to encode all the requisite information into it is a maintenance nightmare. Some (IMO misguided) authors try to do this to some extent or other. Sometimes they do this in the name of making users' lives easier; and more often than not in such cases, I see this resulting in badly broken edge cases. Sometimes they do it just because they think that's what they're supposed to do.

I can see how they get that impression. After all, configure *does* check for dependencies. But a well-written configure does so in the most general way that's practical. That is, rather than check for the existence of a specific package, it's better to check if broader requirements are met by whatever happens to be available on the system.

The applicability of this approach becomes somewhat obfuscated as dependencies migrate farther up the application stack and away from the POSIXy underpinnings. E.g., GLib's functions are never provided by anything other than GLib, so why shouldn't I just check for GLib? Or even more specifically, if you know a particular function you use first appeared in GLib 2.12, why not check for that version?

For something like GLib, there's rarely a reason not to take exactly the course described above.[*] But not all dependencies are like this. For instance, my project uses the Mozilla JavaScript runtime, SpiderMonkey. SpiderMonkey has a stand-alone distribution; but it's also packaged with XULRunner. In this particular case, the library name differs between these distributions--but there's no reason that has to be the case in such a situation. I'd prefer not to tie my users to one of these distributions or the other because, for various reasons, users might find either of these sources for the dependency more convenient.

If the situation with SpiderMonkey strikes anyone as an edge case--well, from a certain perspective, it is. But it's been my experience that cross-platform development has a lot of edges.

So if you wanted to, yes, you could spend a lot of effort encoding a lot of distribution-specific dependency information into And you could spend a lot more effort maintaining it. In the process, you would probably inadvertently reduce the resilience of your configure script to systems you'd never used before. And you'd still have to deal with the hard stuff pretty much the same as before.

If you want a turnkey solution for unsophisticated users, configure is a fine thing to encapsulate. But it is a horrible thing to extend for this purpose.

[*] Even in this case it's arguably better to write a test for the availability of the function you need. Though pragmatically, sometimes this level of resilience just isn't perceived as necessary. If you have a good deal of faith in a library not to make subtractive API changes, a version check is likely to be sufficient.

Braden McDaniel                      e-mail: <address@hidden>
<>               Jabber: <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]