Hello Warren, Many thanks for providing all these useul comments.
Warren Young (2015/09/04 12:27 -0600): > 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. Sure. > 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. You mean that the configure script should check for them and just report an error if they are not found? I think the very reason why the former developers of this project hav chosen to use bundles is to avoid users having to install libraries for a language they don't know and don't know the tools to install them. So a script reporting an error and failing would probably not be satisfactory for those persons -- it would be for me, though. > > 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 understand your point and find it very true. It's just that so far my experience of bundles is different and not as positive than the one you describe. So far, I find that having bundles makes the build system more complex and difficult to maintain. > >> 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. Perhaps, indeed. So, is there a way to have all these macros that detect the OCaml-related tools integrated to the autoconf distribution? > > 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. Would the gain in complexity really be that interesting? Apart from the tar -xzf command that one could remove, where do you think one could spare complexity? > 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. I fully agree with this. Thanks again! Sébastien. > _______________________________________________ > Autoconf mailing list > Autoconf@gnu.org > https://lists.gnu.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf