[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: autocon and sub-packages
From: |
Warren Young |
Subject: |
Re: autocon and sub-packages |
Date: |
Fri, 4 Sep 2015 13:45:49 -0600 |
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.
- Re: autocon and sub-packages, (continued)
- Re: autocon and sub-packages, Eric Blake, 2015/09/04
- Re: autocon and sub-packages, Sébastien Hinderer, 2015/09/04
- Re: autocon and sub-packages, Earnie, 2015/09/04
- Re: Handling of sub-packages by autoconf interfaces, SF Markus Elfring, 2015/09/04
- Re: autocon and sub-packages, Ralf Corsepius, 2015/09/04
- Re: autocon and sub-packages, Sébastien Hinderer, 2015/09/04
- Re: autocon and sub-packages, Wookey, 2015/09/04
- Re: autocon and sub-packages, Warren Young, 2015/09/04
- Re: autocon and sub-packages, Sébastien Hinderer, 2015/09/04
- Re: Handling of sub-packages by autoconf interfaces, SF Markus Elfring, 2015/09/04
- Re: autocon and sub-packages,
Warren Young <=
- Re: autocon and sub-packages, Warren Young, 2015/09/04
- Re: Handling of sub-packages by autoconf interfaces, SF Markus Elfring, 2015/09/05