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@xxxxxxx > https://lists.gnu.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
