Ralf Wildenhues wrote: > If the dependencies are already listed in apt's database, then 'apt-get > build-dep libfoo' should be all you ever need. If not, then I don't see > how Autoconf can behave better than it does now: the mapping of software > given as source to packaging names is still quite distribution-dependent. Another issue is that sometimes you specifically *don't* want optional functionality enabled, and you *do* want those library tests to fail. Say I'm running a standard home workstation with no LDAP server to be found and I'm building a package that has optional LDAP support. I'd be very annoyed if this configure script automatically installed openldap headers and libraries in order to enable functionality that I have specifically decided that I don't want or need. And this gets even worse when packages have optional language bindings. Suppose I have no personal interest in or need for python but I'm building a package with optional python module bindings. I'd be quite annoyed if this supposedly helpful feature decided that I now need all of python installed just so it can enable an optional binding that I'll never use. The quintessential example of this kind of insanity would be php, which has about three dozen various optional library bindings. If the configure script tried to helpfully auto-install all that cruft I think it would be met with a swift control-C followed by nasty words from the user. My observation is that people that are building from source do so because they want to have some measure of extra control that the binary packages don't afford them, and this runs contrary to that notion. If the kitchen sink build was the actual desired behavior it can be had with "apt-get build-dep php5" anyway, as Ralf said. Brian _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
