[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add msgpack

From: Ludovic Courtès
Subject: Re: [PATCH] Add msgpack
Date: Tue, 21 Jun 2016 16:11:47 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)


Lukas Gradl <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>> Hello!
>> Sorry for the late reply, but…
>> Lukas Gradl <address@hidden> 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’m curious, but this shouldn’t block the process, as Leo 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 <zlib.h>
> These two files do get installed in the store, but their compiled
> counterparts do not.

OK, this is a justification for putting zlib in ‘propagated-inputs’
rather than ‘inputs’ (the manual mentions this as one of the valid
justifications for ‘propagated-inputs’ (info "(guix) package 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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]