On Sep 4, 2015, at 12:46 PM, Sébastien Hinderer wrote: > > Warren Young (2015/09/04 12:27 -0600): > >> 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? Yes. It’s a very common thing for autoconfiscated packages to do, because it’s superior to failing at compile time. > ...to avoid users having to install libraries for > a language they don't know and don't know the tools to install them. An inability to cope with compilers and libraries is not a good enough reason to bundle dependencies. Your users have already unpacked your package and are trying to build it, after all. If your users are so clueless that they can’t install your prereqs, they probably can’t install your package, either. A better reason is simply to save people time chasing dependencies. Does OCaml have a widely-used package manager, a la gem, npm, cpan, nuget…? If so, it may be sufficient simply to give the command that installs all the prereqs in your package’s build instructions. If not, then bundling them might indeed be the best plan. > so far my > experience of bundles is different and not as positive than the one you > describe. So, “ineffective,” then, not “bad”. :) Remediation in place may be better than replacement. > So, is there a way to have all these macros that detect the OCaml-related > tools integrated to the autoconf distribution? I’m certain that patches would be thoughtfully considered. :) If your patch is rejected, there are a couple of autoconf macro hosting sites. Merely having a canonical version of a macro may lead, over time, to less divergence in distributed macro versions. >>> 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? I’m referring to the fact that with embedded tarballs, you can’t call AC_CONFIG_SUBDIRS() to make the top-level configure script call the subpackage configure scripts. Because unpacking the tarballs is conditional, your main software package must be reinventing this wheel, and therefore probably missing out on some of the 20 years of wisdom embedded within autoconf, such as how to pass along things like --prefix, how to handle separate build and source trees, etc. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
