Re: autocon and sub-packages

[Warren Young]

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.