unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
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?


  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).