Re: Dealing with language bindings for libraries.

[Catonano]

2018-05-10 11:27 GMT+02:00 Fis Trivial <address@hidden>:

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.

Ah, now I see what you mean.

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

In my view, this is a form of bundling

Some projects bundle some libraries

This make life harder for packagers

It' s frown upon and considered a bad habit

In fact, in the Guix manual there' s a list of chacks to do when you review a new package, submitted onto the mailing list

And one of the checks is to see if the packag _bundles_ anything and if it doesm to try to unbundle and link to system provided resources instead

I think this case is similar

I understand it's boring but I think the right thing to do would be to unbundle also in this case

Complicating the semantics of the packages (what a package is) is a risky business.

Of course I'm the less competent system engineer and packager worldwide and this is just my opinion 🙂