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: <braden@xxxxxxxxxxxxx>
<http://endoframe.com> Jabber: <braden@xxxxxxxxxx>
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
