[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 12:27:51 -0600 |
On Sep 4, 2015, at 6:26 AM, Sébastien Hinderer wrote:
>
> Eric Blake (2015/09/04 06:07 -0600):
>>
>> https://www.gnu.org/software/gettext/manual/gettext.html#AM_005fGNU_005fGETTEXT
>> https://www.gnu.org/software/libtool/manual/libtool.html#Distributing-libltdl
>
> Thank. I think the bundle approach is favoured because the Objective
> Camllanguage and its libraries are not as widespread as gettext and
> libtool.
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.
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.
> 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'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.
> 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.
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.
- autocon and sub-packages, Sébastien Hinderer, 2015/09/03
- Re: Handling of sub-packages by autoconf interfaces, SF Markus Elfring, 2015/09/04
- 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 <=
- 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, 2015/09/04
- Re: autocon and sub-packages, Warren Young, 2015/09/04
- Re: Handling of sub-packages by autoconf interfaces, SF Markus Elfring, 2015/09/05