Hi, Thanks for your answer
Am 12.06.2016 um 14:38 schrieb 宋文武: > Hartmut Goebel <h.goe...@crazy-compilers.com> writes: >> For for I understand. But then the manual says: >> >> ‘native-inputs’ is typically used to list tools needed at >> build time, but not at run time, such as Autoconf, Automake, >> pkg-config, Gettext, or Bison. >> >> The first sentence implies that "inputs" are treated as needed at run >> time. > No, as _native_ inputs usually are tools for building (and testing), > most time they’re not needed at run time. This paragraph is only talking about "native-inputs" and about "needed … not at run time". While the paragraph just above this sentence is talking about both "inputs" and native-inputs", this "needed … not at run time" implies "inputs" are needed at run time. I suggest rephrasing this into something like: "Both inputs and native-inputs are used for stuff needed at build time, not at run time. 'inputs' are for ..., e.g. library headers, ..., while 'native-inputs' are for tools such as Autoconf, Automake, pkg-config, Gettext, or Bison." > >> If so, how can I as a packager find out if eg. libBBB is only used at >> build time and libCCC need to be a propagated input? > By looking the output of ‘guix gc –-references …’, the build time ones > are ones not there. I'm the packager, so I'm the one who needs to *define* the dependencies. There is no ‘guix gc –-references …’ I can query. So *I* need a way to determine whether an input needs to be propagated or not. > >> Same for pkg-config: How to determine if this is only needed ar build >> time (as I would always expect)? The manual says: >> >> … propagated-inputs … >> For example this is necessary when a C/C++ library needs >> headers of another library to compile, or when a pkg-config >> file refers to another one via its ‘Requires’ field. >> >> For me this is confusing. > Many build systems use ‘pkg-config’ to check for libraries and get > flags, a pc file usually list some other packages in its ‘Requires’ > field, if one of these packages is missing (doesn’t have a <package>.pc > file in PKG_CONFIG_PATH), this pc file will be treated as broken, and > the package will be reported as ‘not found’. So propageted these > packages make ‘pkg-config’ works, reduce the work for packaging its > users (otherwise, those packages need to added as inputs even they’re > not used directly). Thanks, I misunderstood the example. I though it was talking about "pkg-config", while it is talking about .pc files. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
