Re: autocon and sub-packages

[Warren Young]

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.