Hi John,
>> This importer does not solve the declarations, and IMHO it should not
>> anyway - as the are dependencies of another packages, which might change
>> over time.
>>
> I’m not sure I fully understand why the recursive importer should not
> solve the transitive dependencies. Could you elab
Hi Hartmut,
> My point is less the work, but the non-transitive declarations:
nettle-sys is an multi-indirect input for sequioa-sqv, still the later
needs to specify these dependencies.
Totally agree. I think everyone agreed, too. A few months ago we decided that
the package inputs should match
Am 09.03.20 um 15:00 schrieb John Soo:
>> - nettle-src, since it is "optional" for nettle-sys - and the phase was
>> not executed.
>> - bindgen, since it is required to build nettle-sys
>> - lalrpop, since it is required for building sequoia-openpgp
>
> That is a lot of work! […] Also I found the
Hi Hartmut,
> On Mar 9, 2020, at 2:26 AM, Hartmut Goebel
> wrote:
>
A second dependancy is "sequoia-openpgp", which requires rhe lalrpop
parser generator for building.
Now when building `sequioa-sqv`, I need to add all these dependencies again:
- nettle-src, since it is "optional" for nettle
On Mon, Mar 09, 2020 at 10:26:01AM +0100, Hartmut Goebel wrote:
> Am 08.03.20 um 21:10 schrieb John Soo:
> > Hmm. Can you elaborate more on “not able to build non-trivial rust
> > applications”?
>
> I'm working on packaging sequoia-openpgp.org.
>
> This requires nettle-sys, a FFI to nettle. nett
Am 08.03.20 um 21:10 schrieb John Soo:
> Hmm. Can you elaborate more on “not able to build non-trivial rust
> applications”?
I'm working on packaging sequoia-openpgp.org.
This requires nettle-sys, a FFI to nettle. nettly-sys "optionally"
requires "nettle-src". I added a phase to "nettle-sys" to
Also I should just say thank you for taking interest in the cargo-build system.
Please let me know if I’m missing something.
John
Hi Hartmut,
> On Mar 8, 2020, at 10:16 AM, Hartmut Goebel
> wrote:
The much more serious issue is that we are not able to build non-trivial
Rust applications: Given a package which needs to add phases, e.g. for
fixing Cargo.toml, we would need to run each package's phases when
building any depe
Hi John,
> My proposal is to:
> * move cargo-{development-}inputs into inputs, requiring only the source from
> libraries.
> * either:
> - move the rust closure function so all packages use it
> Or
> - adjust the transitive closure function such that it works on normal
> inputs rather than ar
Hi Hartmut,
I agree with you. It seems like a problem for cargo to solve to me. Efraim
tried to use the .rlib files to make library files and found it was not really
an option.
There are more problems, too. The way inputs are done doesn’t fit well with the
rest of guix tooling and doesn’t rea
Hi,
I just package "nettle-sys", which are binding for the nettle crypto
library. Builiding these bindings takes quite some time, some native
inputs and - worst of all - some special phases. After building, the
output is empty (beside some license files). Now when building `nettle`,
which depends
11 matches
Mail list logo
