From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Becze Subject: Re: Overhauling the cargo-build-system Date: Mon, 09 Dec 2019 12:14:32 -0800 Message-ID: <54c5406ab3152fa0116a1bc5565e47c6@riseup.net> References: <20191010155056.GD1301@E5400> <87d0f4p6xd.fsf@gnu.org> <20191011141342.GC13364@E5400> <20191010155056.GD1301@E5400> <87d0f4p6xd.fsf@gnu.org> <20191011141342.GC13364@E5400> <87imnjtsk3.fsf@gnu.org> <20191117071934.GC12423@E5400> <20191010155056.GD1301@E5400> <87d0f4p6xd.fsf@gnu.org> <20191011141342.GC13364@E5400> <87imnjtsk3.fsf@gnu.org> <87imnjtsk3.fsf@gnu.org> <87h82ap0oc.fsf_-_@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:54234) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iePQT-0007J5-6Y for guix-devel@gnu.org; Mon, 09 Dec 2019 15:14:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iePQR-0005mt-Me for guix-devel@gnu.org; Mon, 09 Dec 2019 15:14:36 -0500 In-Reply-To: <87h82ap0oc.fsf_-_@gmail.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Chris Marusich Cc: guix-devel@gnu.org 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