2018-05-10 11:27 GMT+02:00 Fis Trivial <ybbs.daans@hotmail.com>:

>
> Catonano writes:
>
> > 2018-05-09 17:21 GMT+02:00 Fis Trivial <ybbs.daans@hotmail.com>:
> >
> >>
> >> 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 🙂