Ludovic Courtès writes: >> I tried this! The dependencies look OK, but the package won't build -- >> there's no tar, make etc. > > Ah, true! > >> ...but that looks a bit strange: if we have to mention the inputs a >> second time the advantage over using the `gnu-make-no-implicit-inputs' >> package description becomes real small? > > The key thing is that ‘package-with-explicit-inputs’ works recursively: > it adds (it does *not* replace) inputs to the whole package graph.
Ah, cool! > Consider this: > > (define x > (let ((p (package-with-explicit-inputs gnu-make > (%bootstrap-inputs+toolchain) > …))) > …)) > > Here ‘%bootstrap-inputs+toolchain’ is called from the top level, when > ‘%current-system’ has its default value. So if you’re on x86_64, you > get the x86_64 inputs. Doh'! The let is at toplevel...yeah that makes sense. > So it’s not a bug per se, but it’s definitely an annoyance. I agree, indeed it's rather a problem of interaction between --system/(%current-system). > I just realized that there’s already a fix for this, which is to pass > ‘package-with-explicit-inputs’ a procedure rather than the input list, > like this: > > (package-with-explicit-inputs gnu-make > %bootstrap-inputs+toolchain > …) > > Does it work for you? Yes! I'm reverting my `...leak' commits and create thunks as input of package-with-explicit-inputs. Thanks! janneke
