From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catonano Subject: Re: Dealing with language bindings for libraries. Date: Thu, 10 May 2018 17:08:27 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000050194b056bdb640c" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39624) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fGnBI-0001N2-UH for guix-devel@gnu.org; Thu, 10 May 2018 11:08:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fGnBF-00052f-Fp for guix-devel@gnu.org; Thu, 10 May 2018 11:08:30 -0400 Received: from mail-yb0-x235.google.com ([2607:f8b0:4002:c09::235]:34287) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fGnBF-00052W-9V for guix-devel@gnu.org; Thu, 10 May 2018 11:08:29 -0400 Received: by mail-yb0-x235.google.com with SMTP id b14-v6so767190ybk.1 for ; Thu, 10 May 2018 08:08:29 -0700 (PDT) In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Fis Trivial Cc: guix-devel --00000000000050194b056bdb640c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-05-10 11:27 GMT+02:00 Fis Trivial : > > Catonano writes: > > > 2018-05-09 17:21 GMT+02:00 Fis Trivial : > > > >> > >> 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 an= y > > 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 =F0=9F=99=82 --00000000000050194b056bdb640c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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++ an= d have
>> multiple language bindings, each of them has their corresponding b= uild
>> 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 inv= oke
>> its build system.
>>
>> For packaging them in guix, one way to deal with it is building ea= ch
>> 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 languag= e
>> binding. But it will result in a huge waste of computing resource.= I
>> don't want to waste precious computing time of guix's buil= d farm.
>>
>
> Maybe I'm being naive, but I don't understand why this would i= nvolve 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 i= s
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 b= undle some libraries

This make life= harder for packagers

It' s fro= wn upon and considered a bad habit

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

And one of the checks is to see if the packag _bundles_ an= ything and if it doesm to try to unbundle and link to system provided resou= rces instead

I think this case is similar

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

Com= plicating the semantics of the packages (what a package is) is a risky busi= ness.

Of course I'm the less competent system engineer and packager world= wide and this is just my opinion =F0=9F=99=82
--00000000000050194b056bdb640c--