2018-05-10 11:27 GMT+02:00 Fis Trivial <[email protected]>: > > Catonano writes: > > > 2018-05-09 17:21 GMT+02:00 Fis Trivial <[email protected]>: > > > >> > >> 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 🙂
