Hello! Lukas Gradl <lgr...@openmailbox.org> skribis:
> l...@gnu.org (Ludovic Courtès) writes: > >> Hello! >> >> Sorry for the late reply, but… >> >> Lukas Gradl <lgr...@openmailbox.org> 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’.
