cargo-build-system: cargo-build-flags: --cfg=unix in package recipe

cargo-build-system: cargo-build-flags: --cfg=unix in package recipe

[Danny Milosavljevic]

Hi,

so it seems I got the cargo-build-system to work for large-ish Rust dependency trees now. It still can't pick up transitive dependencies but hey :P

However, some of the Rust crates have a "windows" target which fails.

For these I'd like to pass "--cfg=unix" and I'd like to put it into the package recipe and not hardcode it into the build system.

I saw that there's a "cargo-build-flags" parameter. However, specifying it like

  (arguments
   `(#:cargo-build-flags '("--cfg=unix" "--release")))

gives me "invalid keyword argument"... 

Why?

Re: cargo-build-system: cargo-build-flags: --cfg=unix in package recipe

[Danny Milosavljevic]

It was missing in guix/build-system/cargo.scm cargo-build as a keyword parameter.

Adding

 (define* (cargo-build store name inputs
                       #:key
                       (tests? #t)
                       (test-target #f)
-                      (configure-flags #f)
+                      (configure-flags #f) ; XXX unused
+                      (cargo-build-flags ''("--release"))
                       (phases '(@ (guix build cargo-build-system)
                                   %standard-phases))
                       (outputs '("out"))
@@ -89,6 +99,7 @@ to NAME and VERSION."
                                  source))
                     #:system ,system
                     #:test-target ,test-target
+                    #:cargo-build-flags ,cargo-build-flags
                     #:tests? ,tests?

makes it work.

Re: cargo-build-system: cargo-build-flags: --cfg=unix in package recipe

[Danny Milosavljevic]

> It still can't pick up transitive dependencies but hey :P

Aha! It can - if one uses propagated-inputs in the package recipes. I think the importer should propagate inputs if the current package is Rust-source-only. Otherwise packages further down the dependency graph (further to the clients) won't compile later.

Re: cargo-build-system: cargo-build-flags: --cfg=unix in package recipe

[David Craven]

> Aha! It can - if one uses propagated-inputs in the package recipes. I think the importer should propagate inputs if the current package is Rust-source-only. Otherwise packages further down the dependency graph (further to the clients) won't compile later.

One of the ideas behind the [replace] stuff in the Cargo.toml file was
to retain the required dependencies.

> However, some of the Rust crates have a "windows" target which fails.
> For these I'd like to pass "--cfg=unix" and I'd like to put it into the package recipe and not hardcode it into the build system.

Nice, didn't know about this flag. That explains why it refused to
build without the windows dependencies.

Re: cargo-build-system: cargo-build-flags: --cfg=unix in package recipe

[ng0]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> Hi,
>
> so it seems I got the cargo-build-system to work for large-ish Rust dependency trees now. It still can't pick up transitive dependencies but hey :P
>
> However, some of the Rust crates have a "windows" target which fails.
>
> For these I'd like to pass "--cfg=unix" and I'd like to put it into the package recipe and not hardcode it into the build system.
>
> I saw that there's a "cargo-build-flags" parameter. However, specifying it like
>
>   (arguments
>    `(#:cargo-build-flags '("--cfg=unix" "--release")))
>
> gives me "invalid keyword argument"... 
>
> Why?
>
>

It does indeed, and this would fix the bug I filed.
I've cut down the number of crates I packaged from 160 to 81 just
by removing the *32-sys and winapi dependencies after reading a
bit about the system.

-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org

Re: cargo-build-system: cargo-build-flags: --cfg=unix in package recipe

[Danny Milosavljevic]

On Tue, 3 Jan 2017 11:57:48 +0100
David Craven <david@craven.ch> wrote:

> > For these I'd like to pass "--cfg=unix" and I'd like to put it into the package recipe and not hardcode it into the build system.  
> 
> Nice, didn't know about this flag. That explains why it refused to
> build without the windows dependencies.

I take it back. It's not that easy, unfortunately. That flag either doesn't exist anymore or not yet in stable. In any case while there are forum posts about it it doesn't actually work.

Re: cargo-build-system: cargo-build-flags: --cfg=unix in package recipe

[Danny Milosavljevic]

Hi ng0,

On Tue, 03 Jan 2017 11:19:55 +0000
ng0 <ng0@libertad.pw> wrote:

> It does indeed, and this would fix the bug I filed.
> I've cut down the number of crates I packaged from 160 to 81 just
> by removing the *32-sys and winapi dependencies after reading a
> bit about the system.

Just a heads-up, if there's a Cargo.lock file (e.g. Rust application) and you do that it will invalidate it. Happened to me. That's why in the WIP patch I don't remove the *32-sys and winapi dependencies if there is a Cargo.lock .

Re: cargo-build-system: cargo-build-flags: --cfg=unix in package recipe

[ng0]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> Hi ng0,
>
> On Tue, 03 Jan 2017 11:19:55 +0000
> ng0 <ng0@libertad.pw> wrote:
>
>> It does indeed, and this would fix the bug I filed.
>> I've cut down the number of crates I packaged from 160 to 81 just
>> by removing the *32-sys and winapi dependencies after reading a
>> bit about the system.
>
> Just a heads-up, if there's a Cargo.lock file (e.g. Rust application) and you do that it will invalidate it. Happened to me. That's why in the WIP patch I don't remove the *32-sys and winapi dependencies if there is a Cargo.lock .
>

Sorry, I'm not a rust developer and after dropping the packaging
process for rust itself sometime in march, I only started on 1st
january with packaging rust and looking into rust again. Can you
explain what you mean?
Unfortunately due to technical reassons I can't give you
view/read access to the branch, so if there's something terribly
wrong/missing you will be able to comment on the weekend or in
the following week. For me it seems to work.
-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org

Re: cargo-build-system: cargo-build-flags: --cfg=unix in package recipe

[David Craven]

> Unfortunately due to technical reassons I can't give you
> view/read access to the branch, so if there's something terribly
> wrong/missing you will be able to comment on the weekend or in
> the following week. For me it seems to work.

Looking forward to seeing your ideas/solution!

Re: cargo-build-system: cargo-build-flags: --cfg=unix in package recipe

[Danny Milosavljevic]

Hi David,

On Tue, 3 Jan 2017 11:57:48 +0100
David Craven <david@craven.ch> wrote:

> > Aha! It can - if one uses propagated-inputs in the package recipes. I think the importer should propagate inputs if the current package is Rust-source-only. Otherwise packages further down the dependency graph (further to the clients) won't compile later.  
> 
> One of the ideas behind the [replace] stuff in the Cargo.toml file was
> to retain the required dependencies.

Just to be sure, I mean if it's two hops away.

If rust-a requires rust-b and rust-b requires rust-libc, then rust-a won't find rust-libc. Maybe it doesn't directly use it but since compilation of rust-a will also compile (compile!) rust-b, that compilation needs rust-libc but can't find it. Not sure how "replace" would have helped this specific situation...

Re: cargo-build-system: cargo-build-flags: --cfg=unix in package recipe

[ng0]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> On Tue, 3 Jan 2017 11:57:48 +0100
> David Craven <david@craven.ch> wrote:
>
>> > For these I'd like to pass "--cfg=unix" and I'd like to put it into the package recipe and not hardcode it into the build system.  
>> 
>> Nice, didn't know about this flag. That explains why it refused to
>> build without the windows dependencies.
>
> I take it back. It's not that easy, unfortunately. That flag either doesn't exist anymore or not yet in stable. In any case while there are forum posts about it it doesn't actually work.

Can we package rust nightly instead?
The ABI is stable nowhere, but nightly has all the features while
stable is limited.

-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org

Re: cargo-build-system: cargo-build-flags: --cfg=unix in package recipe

[David Craven]

> Can we package rust nightly instead?
> The ABI is stable nowhere, but nightly has all the features while
> stable is limited.

I doubt that this solves any underlying problem. This was one of my
initial thoughts too. I've already tried these superficial hacks that
try to avoid the problem. But I'm having a hard time convincing people
that the problems are "fundamental" and no amount of superficial hacks
is going to fix circular dependencies etc. etc.

But again I may be wrong and I always say don't take my word for it.
If you find that it fixes the problem, you are welcome to submit some
patches for review.

Re: cargo-build-system: cargo-build-flags: --cfg=unix in package recipe

[Danny Milosavljevic]

I'm against packaging unstable stuff. We would be packaging a moving target where everything breaks every day. Let's not.

There's a reason there are stable releases (of anything): there's (supposed to be) a (social) guarantee that the API doesn't change in incompatible ways.

If a library doesn't work in a stable release, upstream has to get it to work. Simple as that.
Otherwise it just shouldn't be packaged. People can still use cargo to install it so we aren't preventing anyone from using it.

That said, there could be a rustc-devel package (only for rustc). Other packages, people should be on their own.

Please, let's not make unstable stable by decree. If anything, upstream should just release more stuff as stable (if it's stable) :P

Re: cargo-build-system: cargo-build-flags: --cfg=unix in package recipe

[ng0]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> I'm against packaging unstable stuff. We would be packaging a moving target where everything breaks every day. Let's not.
>
> There's a reason there are stable releases (of anything): there's (supposed to be) a (social) guarantee that the API doesn't change in incompatible ways.
>
> If a library doesn't work in a stable release, upstream has to get it to work. Simple as that.
> Otherwise it just shouldn't be packaged. People can still use cargo to install it so we aren't preventing anyone from using it.
>
> That said, there could be a rustc-devel package (only for rustc). Other packages, people should be on their own.
>
> Please, let's not make unstable stable by decree. If anything, upstream should just release more stuff as stable (if it's stable) :P
>

I agree. I think it's not a solution we should try unless we
haven't tried every possible solution out there.
-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org