From mboxrd@z Thu Jan 1 00:00:00 1970 From: iyzsong@member.fsf.org (=?utf-8?B?5a6L5paH5q2m?=) Subject: Re: inputs vs. native-inputs vs. propagated-inputs Date: Sun, 12 Jun 2016 20:38:57 +0800 Message-ID: <877fdur38e.fsf@member.fsf.org> References: <575D2646.6030000@crazy-compilers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bC4fc-0006uA-1q for help-guix@gnu.org; Sun, 12 Jun 2016 08:39:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bC4fX-0005A4-3E for help-guix@gnu.org; Sun, 12 Jun 2016 08:39:15 -0400 Received: from mail.openmailbox.org ([62.4.1.34]:44684) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bC4fW-00059s-PE for help-guix@gnu.org; Sun, 12 Jun 2016 08:39:11 -0400 In-Reply-To: <575D2646.6030000@crazy-compilers.com> (Hartmut Goebel's message of "Sun, 12 Jun 2016 11:07:18 +0200") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Hartmut Goebel Cc: help-guix Hartmut Goebel writes: > Hi, > > I'm a bit confused about the difference between inputs, native-inputs > and propagated-inputs. > > The manual states: > > The distinction between =E2=80=98native-inputs=E2=80=99 and =E2= =80=98inputs=E2=80=99 is > necessary when considering cross-compilation. When > cross-compiling, dependencies listed in =E2=80=98inputs=E2=80= =99 are built for > the _target_ architecture; conversely, dependencies listed in > =E2=80=98native-inputs=E2=80=99 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: > > =E2=80=98native-inputs=E2=80=99 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=E2=80=99re 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 =E2=80=98guix gc =E2=80=93-references =E2=80=A6=E2=80=99). When you dow= nload a store item by substitutes, its dependencise will be downloaded too. When you install a store item by =E2=80=98guix package -i /gnu/store/=E2=80=A6=E2=80= =99, 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 =E2=80=98propagated-inputs=E2=80=99 will be ad= ded 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=E2=80=99s a dependency of libAAA, but this dependency maybe transparent if the use of libAAA doesn=E2=80=99t requires libAAA. - To build libAAA natively, be inputs is enougth. - To build libAAA for other architecture, pkg-config needed to be =E2=80=98native-inputs=E2=80=99, due to it=E2=80=99s 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=E2=80= =99s headers or its .pc file list libCCC in the =E2=80=98Requires=E2=80=99 fie= ld.). > > 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 =E2=80=98guix gc =E2=80=93-references =E2=80=A6=E2= =80=99, the build time ones are ones not there. If you think something shouldn=E2=80=99t be there (eg: build a library, but gcc end up within its references), then it=E2=80=99s t= ime to patch it to reduce closure size. For propagated inputs, it=E2=80=99s 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: > > =E2=80=A6 propagated-inputs =E2=80=A6 > 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 =E2=80=98Requires=E2=80=99 f= ield. > > For me this is confusing. Many build systems use =E2=80=98pkg-config=E2=80=99 to check for libraries = and get flags, a pc file usually list some other packages in its =E2=80=98Requires= =E2=80=99 field, if one of these packages is missing (doesn=E2=80=99t have a .pc file in PKG_CONFIG_PATH), this pc file will be treated as broken, and the package will be reported as =E2=80=98not found=E2=80=99. So propageted= these packages make =E2=80=98pkg-config=E2=80=99 works, reduce the work for packa= ging its users (otherwise, those packages need to added as inputs even they=E2=80=99= re not used directly).