From: Peter Polidoro <peter@polidoro.io>
To: Julien Lepiller <julien@lepiller.eu>
Cc: help-guix@gnu.org
Subject: Re: Finding Dependencies at Run Time
Date: Thu, 14 Jul 2022 13:47:19 -0400 [thread overview]
Message-ID: <86cze77bm2.fsf@polidoro.io> (raw)
In-Reply-To: <AC9B4F6C-DA90-4D2A-B4B7-2DD6245A4D3A@lepiller.eu>
> Remember the difference between inputs and propagated inputs:
> they're the same, but when you create a profile, inputs are not
> part of the
> profile (so they need a direct store reference, such as RPATH or
> a wrapper), whereas propagated inputs are part of the profile,
> so an
> environment variable allows to find them.
Thank you for patiently explaining, I think I am starting to
understand now, but please correct me if I am still wrong.
So there is package build-time, profile build-time, and run-time.
Wrappers should be used to set environment variables when the
value can be determined at package build-time, such as absolute
paths to inputs.
Search paths should be used to set environment variables when the
value will be determined at profile build-time, such as relative
paths to either propagated-inputs or packages that also installed
in the same profile, but not listed explicitly as
propagated-inputs to the package declaring the search paths.
I am still a little unclear about the difference between
search-paths and native-search-paths, though. If not
cross-compiling then they act the same? If you are
cross-compiling, though, then it only finds packages that are
listed as native-inputs to the package declaring the search paths?
Native-inputs are not normally installed in a profile, though,
correct? Does that mean native-search-paths will only be found
when using a development shell when cross-compiling?
I guess I do not properly understand cross-compiling. So when
cross-compiling, there is a package build-time, where you are
building packages for a target architecture on a host machine,
profile build-time, where you are building a profile on the
target, and run-time, when you are running on the target? If
search-paths and native-search-paths are determined at profile
build-time, how do they behave differently on the target machine?
next prev parent reply other threads:[~2022-07-14 19:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-13 14:56 Finding Dependencies at Run Time Peter Polidoro
2022-07-13 16:03 ` Julien Lepiller
2022-07-13 17:47 ` Peter Polidoro
2022-07-13 18:39 ` Julien Lepiller
2022-07-13 18:51 ` Peter Polidoro
2022-07-13 21:02 ` Julien Lepiller
2022-07-14 17:47 ` Peter Polidoro [this message]
2022-07-16 21:53 ` Thiago Jung Bauermann
2022-07-14 8:25 ` Ricardo Wurmus
2022-07-14 8:48 ` Philip McGrath
2022-07-14 11:28 ` Ricardo Wurmus
2022-07-14 13:27 ` zimoun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86cze77bm2.fsf@polidoro.io \
--to=peter@polidoro.io \
--cc=help-guix@gnu.org \
--cc=julien@lepiller.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).