unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Martin Becze <mjbecze@riseup.net>
To: Chris Marusich <cmmarusich@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Overhauling the cargo-build-system
Date: Mon, 09 Dec 2019 12:14:32 -0800	[thread overview]
Message-ID: <54c5406ab3152fa0116a1bc5565e47c6@riseup.net> (raw)
In-Reply-To: <87h82ap0oc.fsf_-_@gmail.com>

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	other threads:[~2019-12-09 20:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-10 15:50 Overhauling the cargo-build-system Efraim Flashner
2019-10-10 22:33 ` Ludovic Courtès
2019-10-11 14:13   ` Efraim Flashner
2019-11-16  6:31     ` Martin Becze
2019-11-16 16:37       ` John Soo
2019-11-16 18:44         ` Martin Becze
2019-11-16 21:33       ` Ludovic Courtès
2019-11-17  2:35         ` Martin Becze
2019-11-17  7:19         ` Efraim Flashner
2019-11-17 21:22           ` Ludovic Courtès
2019-11-18 10:20             ` Efraim Flashner
2019-11-23 17:27               ` Ludovic Courtès
2019-12-09  4:45           ` Chris Marusich
2019-12-09 20:14             ` Martin Becze [this message]
2019-12-19 16:10               ` Ludovic Courtès
2019-12-19 16:09             ` Ludovic Courtès
2019-12-19 17:23               ` John Soo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54c5406ab3152fa0116a1bc5565e47c6@riseup.net \
    --to=mjbecze@riseup.net \
    --cc=cmmarusich@gmail.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).