Re: Dealing with language bindings for libraries.

[Fis Trivial]

Catonano writes:

> 2018-05-09 17:21 GMT+02:00 Fis Trivial <address@hidden>:
>
>>
>> Hi, Guixs.
>>
>> Recently I encountered some libraries that's written in c++ and have
>> multiple language bindings, each of them has their corresponding build
>> system, namely, R, Python, Java. And all the bindings are in
>> tree. During the build process, One would first build the c++ part by
>> cmake, then chdir into each language binding sub-directory and invoke
>> its build system.
>>
>> For packaging them in guix, one way to deal with it is building each
>> binding as an independent package, each package has it's own
>> dependencies for the specific binding and common dependencies for C++
>> part, that way, we will have N independent packages, for N language
>> binding. But it will result in a huge waste of computing resource. I
>> don't want to waste precious computing time of guix's build farm.
>>
>
> Maybe I'm being naive, but I don't understand why this would involve any
> further overhead
>
> You could have the c++ part as a dinamically linked library and the
> bindings would have it as a dependency
>
> What's the overhead in this ?

Thanks for the reply.

This is somehow like dealing with git submodules, people just include
submodules' directory in their build system, for example in cmake
script:

add_subdirectory(submodule_directory).

If you want to split it when packaging, you need to write a cmake config
script for that submodule and then patch the outer cmake file for
replacing `add_subdirectory` with `find_package`. I don't think there is
a shortcut for this. But doing so might be welcomed by upstream.


In the case of language binding, the build code for bindings would try
to find the shared object and other meta data required for build inside
build tree, not in system path. And by saying "try to find", it actually
tries to first invoke the c++ build tool(cmake, autotools etc.), then
walk through the build tree to check the shared object. I hope the
following listing can make it a bit clear what happens when building
without package manager:

        1. Build the c++ part in project root /path-to-project/configure

           $ ./configure && make

        2. Change dir into language binding subdirectory

           $ cd /path-to-project/python_binding

           a. Invoke build

              $ python setup.py build

           b. Build code for binding (setup.py in this example) invoke
              make in ../makefile first

           c. The c++ part has already been built manually at step 1,
           nothing needs to be done by make.

           d. Build code (setup.py) walk through the build tree to check
           the shared object built by make, and other required meta
           data.

           e. Build the binding part inside
           /path-to-project/python-binding.

        3. repeat step 2 for other language bindings (replace setup.py
        and directory name for their corresponding build script and
        directory name).

So, to make the c++ part as shared object and let the bindings find it
at compile time, I need to rewrite all the build code for bindings,
which I don't consider necessary for either upstream nor packaging.