Hartmut Goebel <h.goe...@crazy-compilers.com> writes: > Hi, > > I'm a bit confused about the difference between inputs, native-inputs > and propagated-inputs. > > The manual states: > > The distinction between ‘native-inputs’ and ‘inputs’ is > necessary when considering cross-compilation. When > cross-compiling, dependencies listed in ‘inputs’ are built for > the _target_ architecture; conversely, dependencies listed in > ‘native-inputs’ are built for the architecture of the _build_ > machine. Yes, _native_ means the same architecture as the build machine.
> > 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. The dependencies of a store item (an output of the package) is computed by scan all its files for store paths (as reported by ‘guix gc –-references …’). When you download a store item by substitutes, its dependencise will be downloaded too. When you install a store item by ‘guix package -i /gnu/store/…’, only one path will be added to the profile. The runtime dependencies are only for _package_ objects. When you add a _package_ object into profile (or inputs for building other package), its ‘propagated-inputs’ will be added too. > > Now consider libAAA (supporting the famous Amiga AAA chipset ;-), which > requires the headers of libBBB to compile (but only to fetch some > constant definitions) and libCCC at run-time. Without libCCC, libAAA > could not work. And libAAA uses pkg-config to find the header files. > > So for me this would be: > libBBB: inputs > libCCC: propagates inputs > pkg-confg: native inputs > > > Is this correct? No, libCCC not necessary be propagated, it’s a dependency of libAAA, but this dependency maybe transparent if the use of libAAA doesn’t requires libAAA. - To build libAAA natively, be inputs is enougth. - To build libAAA for other architecture, pkg-config needed to be ‘native-inputs’, due to it’s an ELF executable to be invoked by the build system. - To make the users of libAAA happy, libBBB or libCCC should be propagated if the use of libAAA require them (eg: its headers include libBBB’s headers or its .pc file list libCCC in the ‘Requires’ field.). > > 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. If you think something shouldn’t be there (eg: build a library, but gcc end up within its references), then it’s time to patch it to reduce closure size. For propagated inputs, it’s for the users. So if (for programs) we run it fine or (for libraries) include its headers and link it fine, nothing need to be propagated. > > 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).
