From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukas Gradl Subject: Re: [PATCH] Add msgpack Date: Tue, 21 Jun 2016 08:31:10 -0500 Message-ID: <877fdiactd.fsf@openmailbox.org> References: <87wpmbuv6m.fsf@openmailbox.org> <20160606140737.GA26555@jasmine> <20160611030655.GA24837@jasmine> <87lh2b7009.fsf@openmailbox.org> <20160612001750.GA9854@jasmine> <87eg836nm3.fsf@openmailbox.org> <20160613165852.GA31846@jasmine> <20160613175910.GA6456@jasmine> <87fusbyhk7.fsf@openmailbox.org> <8737o9onan.fsf@openmailbox.org> <87porbc4x0.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFLlz-00063Z-8t for guix-devel@gnu.org; Tue, 21 Jun 2016 09:31:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFLlu-0005Ti-Sf for guix-devel@gnu.org; Tue, 21 Jun 2016 09:31:23 -0400 In-Reply-To: <87porbc4x0.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Tue, 21 Jun 2016 10:38:51 +0200") 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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org Hi, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Hello! > > Sorry for the late reply, but=E2=80=A6 > > Lukas Gradl skribis: > >> All the files that do get installed in the output path of >> msgpack in the store do not contain the hash part of the store-path of >> zlib. They only refer to zlib by name. > > What kind of files are these, and how do they refer to zlib exactly? > > (I=E2=80=99m curious, but this shouldn=E2=80=99t block the process, as Le= o wrote.) It is a C Header file and a corresponding C++ Header file (include/msgpack/zbuffer.h[pp]). They refer to zlib by just doing: #include These two files do get installed in the store, but their compiled counterparts do not. Thinking out loud, we could possibly force the creation of a reference to zlib by putting the path of the zlib used when building the package into a comment or a seperate file. On the other hand, I am not so sure if we really want a reference, since, as you said, they are for run-time dependencies. Since msgpack itself does not use zbuffer at run-time (only at build time for tests) and does not provide a library including zbuffer for other packages to link against, the files zbuffer.h[pp] are really not used at run-time. The only time that I can think of when these files could be used is during the build of a dependent package that wants to include these files. Propagating zlib would assure that zlib is available whenever zbuffer.h[pp] gets included by some other package. Maybe this is the right way to represent the situation? Best, Lukas