autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autocon and sub-packages


From: Sébastien Hinderer
Subject: Re: autocon and sub-packages
Date: Fri, 4 Sep 2015 14:26:20 +0200

Dear Eric,

Thanks a lot for your response.

Eric Blake (2015/09/04 06:07 -0600):
> On 09/03/2015 08:09 AM, Sébastien Hinderer wrote:
> > Dear all,
> > 
> > I am one of the maintainers of Coccinelle[1], a tool written in the
> > Objective Caml[2] language.
> > 
> > The tool is distributed with the libraries it depends on (they are
> > provided as bundles).
> 
> At one point, this was how both libintl (gettext) and libltdl (libtool)
> were primarily used - many packages would include subdirectories with
> the appropriate bundled library, and then rely on macros provided by
> gettext/libtool to probe whether to favor the system version if present
> and capable, otherwise fall back to the bundled version.  However, these
> days, most people have leaned towards excluding the bundle, and instead
> requiring the external library to be present.  For more information,
> check out:
> 
> 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. 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.

> > Then, assuming we continue to bundle the dependencies, it seems to me
> > that it would be more coherent to have the configure script of each
> > required bundle run by the tool's main configure script. I am aware of
> > the AC_CONFIG_SUBDIRS macro, but this seems a bit limited to me. For
> > instance it means that the sub-package's configure may find a different
> > compiler to use than the one found by the main conigure, which is not
> > good.
> 
> I'm not sure why you think a different compiler would be picked for a
> sub-package. [...]

Because that already happened. ;-)

The thing is that the macros to detect the OCaml compiler and the
associated tools are not yet included in autoconf. So we provide them in
the tool I am responsible for, and it turns out that one o the bundled
library provides them, too, but in a different version. And the
twoversions of the macro found different compilers. So things are not as
standard and straightforward for OCaml as they are for C-like languages.

> > One other issue is that we bundle the dependencies as .tar.gz archives
> > and we would like to be able to extract the archives only for those
> > dependencies that will really be needed (because they are not already
> > installed on the system). Can this be achieved somehow with autoconf?
> 
> If you can come up with appropriate shell code to do that, then you can
> embed that shell code in your configure.ac. I don't know of any autoconf
> macros that would automate some of the work, but it sounds like it might
> be something that could be cobbled together, if you still want to go the
> route of shipping dependent library bundles.

Thanks. I indeed think it should be possible to achieve this.
As I said I would personally prefer not to bundle libraries but I'm not
in a position where I can take this decision.

Cheers,

Sébastien.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]