guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Overhauling the cargo-build-system


From: Martin Becze
Subject: Re: Overhauling the cargo-build-system
Date: Mon, 09 Dec 2019 12:14:32 -0800

On 2019-12-09 04:45, Chris Marusich wrote:

> input in order to actually build the program.  In this model, I guess
> every "*-src" package would have no inputs and just one output.  I guess
> any package that produces an artifact, for example the "ripgrep"
> package, would list a bunch of "*-src" packages as inputs: one for every
> crate in the transitive closure of dependencies and dev-dependencies of
> the ripgrep crate.  That might solve the problem of cyclic dependencies,
> and it might reduce (but not eliminate) the amount of excessive building
> performed by cargo-build-system.  However, it would make some package
> definitions large, it would introduce duplication of inputs across
> packages that need the same "*-src" inputs, and it would create a lot of
> "*-src" packages.  On the plus side, tools like "guix graph" would work
> as-is; currently, "guix graph" has not been taught to understand
> #:cargo-inputs and #:cargo-development-inputs for cargo-build-system
> packages.

I don't understand why just adding a (skip-build?) to the source rust
packages, dropping their cargo-dev-deps AND leaving the cargo-inputs for
all the rest of the dependencies wouldn't accomplish the same thing. The
thing I object to is having to specify the transient packages at the top
level, since that would be unusable for actually rust development. Is
there any problem with the following example for rust source packages?

(define-public rust-home
  (package
    (name "rust-home")
    (version "0.5.1")
    (source
      (origin
        (method url-fetch)
        (uri (crate-uri "home" version))
        (file-name
          (string-append name "-" version ".crate"))
        (sha256
          (base32
            "1a4wcnadw2sarmisb5bz7gs4qwnijalvbf5gf7kg0wdxyxa3jxd3"))))
    (build-system cargo-build-system)
    (arguments
      `(#:skip-build?
        #t
        #:cargo-inputs
        (("rust-scopeguard" ,rust-scopeguard)
         ("rust-winapi" ,rust-winapi))))
    (home-page "https://github.com/brson/home";)
    (synopsis
      "Shared definitions of home directories")
    (description
      "Shared definitions of home directories")
    (license (list license:expat license:asl2.0))))

(define-public rust-winapi
  (package
    (name "rust-winapi")
    (version "0.3.8")
    (source
      (origin
        (method url-fetch)
        (uri (crate-uri "winapi" version))
        (file-name
          (string-append name "-" version ".crate"))
        (sha256
          (base32
            "1ii9j9lzrhwri0902652awifzx9fpayimbp6hfhhc296xcg0k4w0"))))
    (build-system cargo-build-system)
    (arguments
      `(#:skip-build?
        #t
        #:cargo-inputs
        (("rust-winapi-i686-pc-windows-gnu"
          ,rust-winapi-i686-pc-windows-gnu)
         ("rust-winapi-x86-64-pc-windows-gnu"
          ,rust-winapi-x86-64-pc-windows-gnu))))
    (home-page
      "https://github.com/retep998/winapi-rs";)
    (synopsis
      "Raw FFI bindings for all of Windows API.")
    (description
      "Raw FFI bindings for all of Windows API.")
    (license #f)))


Also see patch 38465
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38465) for a complete
example. I would like too know if there is an problem with this patch
to, before I start packaging the other rust programs this way.

Thanks,
-Martin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]