Re: autocon and sub-packages

[Sébastien Hinderer]

Hello Warren,

Many thanks for providing all these useul comments.

Warren Young (2015/09/04 12:27 -0600):
> 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.

Sure.

> 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?

I think the very reason why the former developers of this project hav
chosen to use bundles is to avoid users having to install libraries for
a language they don't know and don't know the tools to install them. So
a script reporting an error and failing would probably not be
satisfactory for those persons -- it would be for me, though.

> > 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 understand your point and find it very true. It's just that so far my
experience of bundles is different and not as positive than the one you
describe. So far, I find that having bundles makes the build system more
complex and difficult to maintain.

> >> 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.

Perhaps, indeed.

So, is there a way to have all these macros that detect the OCaml-related
tools integrated to the autoconf distribution?

> > 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?

> 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.

I fully agree with this.

Thanks again!

Sébastien.
> _______________________________________________
> Autoconf mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/autoconf