On Sep 4, 2015, at 6:26 AM, Sébastien Hinderer wrote: > > Eric Blake (2015/09/04 06:07 -0600): >> >> https://www.gnu.org/software/gettext/manual/gettext.html#AM_005fGNU_005fGETTEXT >> https://www.gnu.org/software/libtool/manual/libtool.html#Distributing-libltdl > > Thank. I think the bundle approach is favoured because the Objective > Camllanguage and its libraries are not as widespread as gettext and > libtool. Left unsaid in Eric’s answer is that this change in distribution philosophy happened *because* capable versions started appearing everywhere, so it was no longer necessary to provide copies along with the main package. If you’re using libraries that are also not yet ubiquitous, the alternative to providing the sub-packages with the main package is to add a hard-fail autoconf test for them. > So the idea of the bundles is tomake life of end-users simpler, > but of course it also makes thelifeofdevelopers and maintainers a bit > harder. Not necessarily. Just yesterday I was building a package that had some configure-time code in it to select one of several different Tcl interpreter embedding libraries. If it found Tcl 8.6, it would simply link directly to the Tcl development libraries, but otherwise it would use an embedded fork of the Tcl 8.6 libraries with fall-backs that allowed it to link against Tcl 8.5 or 8.4. Without that workaround embedded into the package, my only option would have been to upgrade to Tcl 8.6, or not use the feature that required Tcl 8.6. Software is infinitely malleable, so it allows a grayscale continuum of solutions. There isn’t “good” or “bad,” only “appropriate” and “inappropriate,” or “effective” and “ineffective.” >> I'm not sure why you think a different compiler would be picked for a >> sub-package. [...] > > Because that already happened. ;-) Then it can also happen when these dependencies are external. > I would personally prefer not to bundle libraries I think your main mistake is bundling them as embedded tarballs instead of just shipping them as subdirectories of the lone distribution tarball. It adds complexity, and saves no space in the distribution tarball. It does save a bit of space at build time on the distribution-user’s machine, but we’re long past the days of 5 MB disk drives the size of washing machines. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
