* Why does %build-inputs contain the transitive closure of inputs?!
@ 2020-08-07 23:08 Jakub Kądziołka
2020-08-08 0:26 ` Carlo Zancanaro
0 siblings, 1 reply; 3+ messages in thread
From: Jakub Kądziołka @ 2020-08-07 23:08 UTC (permalink / raw)
To: guix-devel
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
Consider this package:
(use-modules
(guix packages)
(guix build-system trivial)
(gnu packages version-control))
(define foo
(package
(name "foo")
(version "0")
(source #f)
(build-system trivial-build-system)
(arguments
`(#:builder
(begin
(display %build-inputs)
#t)))
(inputs
`(("libgit2" ,libgit2)))
(synopsis "")
(description "")
(home-page "")
(license #f)))
When we try building it, it prints:
((libgit2 . /gnu/store/hlcfmg5n29ynf354x7s4s7bkxswrmkq4-libgit2-1.0.1) (zlib . /gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11) (pcre2 . /gnu/store/ckpchpflfwhag5qsfk8klvmihwzqg9rp-pcre2-10.35) (openssl . /gnu/store/dkzivzn17qilmqdfpyps62b395wxhshh-openssl-1.1.1f))
Why? I would expect only libgit2 to be present, and not all of its
dependencies. It seems to me that this has only downsides - the entire
transitive closure needs to be present during build, even when the
actually used dependencies don't reference it, and the names of inputs
used by packages are now public API, and changing them can break the
build of any transitively dependent package.
I've traced this back to bag->derivation's use of
bag-transitive-inputs, but unfortunately git blame didn't hold any hints
- it has been this way ever since bag->derivation was first implemented.
Am I missing something, or is this a bug?
Regards,
Jakub Kądziołka
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Why does %build-inputs contain the transitive closure of inputs?!
2020-08-07 23:08 Why does %build-inputs contain the transitive closure of inputs?! Jakub Kądziołka
@ 2020-08-08 0:26 ` Carlo Zancanaro
2020-08-08 0:56 ` Jakub Kądziołka
0 siblings, 1 reply; 3+ messages in thread
From: Carlo Zancanaro @ 2020-08-08 0:26 UTC (permalink / raw)
To: Jakub Kądziołka; +Cc: guix-devel
Hi Jakub,
On Sat, Aug 08 2020, Jakub Kądziołka wrote:
> Why? I would expect only libgit2 to be present, and not all of
> its dependencies. ...
If you take a look at the definition for libgit2 in
gnu/packages/version-control.scm you'll see that this isn't all
the dependencies for libgit2, it's only the propagated-inputs. For
instance, libssh2 and http-parser are both inputs for libgit2, but
they don't appear in your list because they're not propagated.
> ... It seems to me that this has only downsides - the entire
> transitive closure needs to be present during build, even when
> the actually used dependencies don't reference it, and the names
> of inputs used by packages are now public API, and changing them
> can break the build of any transitively dependent package.
The way propagated inputs work is that they're installed alongside
the package, so in some sense they are part of the public API of
the package. They should be used with care, but as far as I can
tell everything is working properly here.
Carlo
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Why does %build-inputs contain the transitive closure of inputs?!
2020-08-08 0:26 ` Carlo Zancanaro
@ 2020-08-08 0:56 ` Jakub Kądziołka
0 siblings, 0 replies; 3+ messages in thread
From: Jakub Kądziołka @ 2020-08-08 0:56 UTC (permalink / raw)
To: Carlo Zancanaro; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]
On Sat, Aug 08, 2020 at 10:26:08AM +1000, Carlo Zancanaro wrote:
> Hi Jakub,
>
> On Sat, Aug 08 2020, Jakub Kądziołka wrote:
> > Why? I would expect only libgit2 to be present, and not all of its
> > dependencies. ...
>
> If you take a look at the definition for libgit2 in
> gnu/packages/version-control.scm you'll see that this isn't all the
> dependencies for libgit2, it's only the propagated-inputs. For instance,
> libssh2 and http-parser are both inputs for libgit2, but they don't appear
> in your list because they're not propagated.
>
> > ... It seems to me that this has only downsides - the entire transitive
> > closure needs to be present during build, even when the actually used
> > dependencies don't reference it, and the names of inputs used by
> > packages are now public API, and changing them can break the build of
> > any transitively dependent package.
>
> The way propagated inputs work is that they're installed alongside the
> package, so in some sense they are part of the public API of the package.
> They should be used with care, but as far as I can tell everything is
> working properly here.
You're absolutely right. This even explains the original weirdness I
saw. Serves me right for hacking at 1 AM...
Sorry for the noise :/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-08-08 0:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-08-07 23:08 Why does %build-inputs contain the transitive closure of inputs?! Jakub Kądziołka
2020-08-08 0:26 ` Carlo Zancanaro
2020-08-08 0:56 ` Jakub Kądziołka
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.