From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH] Add msgpack Date: Tue, 21 Jun 2016 16:11:47 +0200 Message-ID: <87shw68wd8.fsf@gnu.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> <877fdiactd.fsf@openmailbox.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]:60521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFMPD-0004BK-0f for guix-devel@gnu.org; Tue, 21 Jun 2016 10:11:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFMP8-0006kC-Nl for guix-devel@gnu.org; Tue, 21 Jun 2016 10:11:54 -0400 In-Reply-To: <877fdiactd.fsf@openmailbox.org> (Lukas Gradl's message of "Tue, 21 Jun 2016 08:31:10 -0500") 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: Lukas Gradl Cc: guix-devel@gnu.org Hello! Lukas Gradl skribis: > 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 L= eo 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. OK, this is a justification for putting zlib in =E2=80=98propagated-inputs= =E2=80=99 rather than =E2=80=98inputs=E2=80=99 (the manual mentions this as one of th= e valid justifications for =E2=80=98propagated-inputs=E2=80=99 (info "(guix) packag= e Reference")). It is worth adding a margin comment with this explanation. > 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? It is. :-) Thanks for explaining! Ludo=E2=80=99.