Re: cargo-build-system: cargo-build-flags: --cfg=unix in package recipe
Danny Milosavljevic 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
Re: cargo-build-system: cargo-build-flags: --cfg=unix in package recipe
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
> 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 writes: > On Tue, 3 Jan 2017 11:57:48 +0100 > David Craven 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
Hi David, On Tue, 3 Jan 2017 11:57:48 +0100 David Craven 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
> 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 writes: > Hi ng0, > > On Tue, 03 Jan 2017 11:19:55 + > ng0 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
Hi ng0, On Tue, 03 Jan 2017 11:19:55 + ng0 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
On Tue, 3 Jan 2017 11:57:48 +0100 David Craven 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 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
> 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
> 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
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.
cargo-build-system: cargo-build-flags: --cfg=unix in package recipe
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?