From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fis Trivial Subject: Re: Dealing with language bindings for libraries. Date: Thu, 10 May 2018 09:27:22 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44039) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fGhrG-0003Fk-NF for guix-devel@gnu.org; Thu, 10 May 2018 05:27:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fGhrB-0006v8-Nn for guix-devel@gnu.org; Thu, 10 May 2018 05:27:30 -0400 Received: from mail-oln040092004036.outbound.protection.outlook.com ([40.92.4.36]:58368 helo=NAM02-CY1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fGhrB-0006tG-5g for guix-devel@gnu.org; Thu, 10 May 2018 05:27:25 -0400 In-Reply-To: Content-Language: en-US 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: Catonano Cc: guix-devel 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 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.