Re: Autoconf and apt

[Braden McDaniel]

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) configure.ac 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 configure.ac. 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>
<http://endoframe.com>               Jabber: <address@hidden>