Re: [PATCH] Add msgpack

[Ludovic Courtès]

Hello!

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!

Ludo’.