Re: autocon and sub-packages

[Earnie]

On 9/4/2015 8:26 AM, Sébastien Hinderer wrote:
> 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.
> 

I'd be inclined to provide binary distributions of those libraries for
the systems I wish to support and not embed bundles in my source.  If
others feel it important for other systems they can provide the binary
distributions for those systems.  There is also the GCC method of if the
library directory exists before configure is executed it schedules the
build of the library.  In this way the build of the library is provided
for by the build system but the source package doesn't contain the
library package itself.

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

To use Eric's term, cobble up some m4 to detect it and provide as a
patch to autoconf.  As for the "one o the bundled libraries provides
them, too" I suggest you work with that library team and correct that
issue.  But since you're bundling the library then you can modify its
macro to match yours before you bundle it.

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

You could let the make do the extraction.  No need to cobble something
in shell code.  Make the extraction via make depend on some missing file.

-- 
Earnie