GNU bug report logs - #46162
[PATCH] staging gnu: Add more tools to rust outputs.

Previous Next

To reply to this bug, email your comments to 46162 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: John Soo <jsoo1 <at> asu.edu>
To: guix-patches <at> gnu.org
Subject: [PATCH] staging gnu: Add more tools to rust outputs.
Date: Thu, 28 Jan 2021 14:00:20 -0800

[Message part 1 (text/plain, inline)]

Hi Guix!

I work with rust for my job and I would love to be able to use clippy
and the other tools that are in the rustc tree.  This patch installs
those tools as other outputs in the same way we have cargo and rustfmt
now.  Thanks!

All the best,

John

[0001-gnu-Add-more-tools-to-rust-outputs.patch (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 46162 <at> debbugs.gnu.org (full text, mbox):

From: John Soo <jsoo1 <at> asu.edu>
To: 46162 <at> debbugs.gnu.org
Subject: Re: bug#46162: [PATCH] staging gnu: Add more tools to rust outputs.
Date: Thu, 28 Jan 2021 15:29:54 -0800

[Message part 1 (text/plain, inline)]

Here is an edited patch. I had rebased incorrectly, my apologies.

- John

[0001-gnu-Add-more-tools-to-rust-outputs.patch (text/x-patch, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #11 received at 46162 <at> debbugs.gnu.org (full text, mbox):

From: John Soo <jsoo1 <at> asu.edu>
To: 46162 <at> debbugs.gnu.org
Subject: Re: bug#46162: [PATCH] staging gnu: Add more tools to rust outputs.
Date: Mon, 15 Feb 2021 08:13:10 -0800

[Message part 1 (text/plain, inline)]

Rebased on staging.

There is one more question that I have about search paths.  A lot of rust
tools use the $RUST_SRC_PATH to find the source of rust.  I add the
source output as "src" but I am not sure how to specify a search path to
the top directory of a separate output.  Any pointers?

Thanks!

John

[0001-gnu-Add-more-tools-to-rust-outputs.patch (text/x-patch, attachment)]

Message #14 received at 46162 <at> debbugs.gnu.org (full text, mbox):

From: John Soo <jsoo1 <at> asu.edu>
To: 46162 <at> debbugs.gnu.org
Cc: kuba <at> kadziolka.net
Subject: Re: bug#46162: [PATCH] staging gnu: Add more tools to rust outputs.
Date: Mon, 15 Feb 2021 10:09:25 -0800

Hi Jakub,

Thanks again for your work on rust.

I cc'd you for feedback on adding the "extended" tools to rust's
outputs.

- John

Message #17 received at 46162 <at> debbugs.gnu.org (full text, mbox):

From: Jakub Kądziołka <kuba <at> kadziolka.net>
To: "John Soo" <jsoo1 <at> asu.edu>, <46162 <at> debbugs.gnu.org>
Subject: Re: bug#46162: [PATCH] staging gnu: Add more tools to rust outputs.
Date: Tue, 16 Feb 2021 00:41:12 +0100

On Mon Feb 15, 2021 at 7:09 PM CET, John Soo wrote:
> Hi Jakub,
>
> Thanks again for your work on rust.
>
> I cc'd you for feedback on adding the "extended" tools to rust's
> outputs.

I don't think tools beyond rustc and cargo should be included in the
main rust package, as this causes them to be built in each step of the
bootstrap. I believe a better approach would be to define separate
packages for them.

We would have something like

 ;; TODO(staging): Bump this variable to the latest packaged rust.
 (define-public rust rust-1.45)

+(define-public rust-for-tools rust-1.50)

I'm not sure if rustbuild can be convinced to not build the compiler
itself when the version used for the build is the same as the sources'.
If so, defining packages for each tool shouldn't need any guix-side
tricks.

Otherwise, I would define a single rust-tools package with
(outputs '("rustfmt" "clippy" ...)). Perhaps it would help with UX if
rust-tools itself was hidden, and instead the tools would be exposed
with simple packages that expose each tool separately, with a symlink or
similar.

I'll see if I can find some time to try this out this week.

Regards,
Jakub Kądziołka

Message #20 received at 46162 <at> debbugs.gnu.org (full text, mbox):

From: John Soo <jsoo1 <at> asu.edu>
To: Jakub Kądziołka <kuba <at> kadziolka.net>
Cc: 46162 <at> debbugs.gnu.org
Subject: Re: bug#46162: [PATCH] staging gnu: Add more tools to rust outputs.
Date: Tue, 16 Feb 2021 08:40:20 -0800

Hi Jakub,

Jakub Kądziołka <kuba <at> kadziolka.net> writes:

> I don't think tools beyond rustc and cargo should be included in the
> main rust package, as this causes them to be built in each step of the
> bootstrap. I believe a better approach would be to define separate
> packages for them.

Yeah that would make sense. Have we explored any of the incremental or
--keep-stage options to speedup the bootstrap?

> We would have something like
>
>  ;; TODO(staging): Bump this variable to the latest packaged rust.
>  (define-public rust rust-1.45)
>
> +(define-public rust-for-tools rust-1.50)
>
> I'm not sure if rustbuild can be convinced to not build the compiler
> itself when the version used for the build is the same as the sources'.
> If so, defining packages for each tool shouldn't need any guix-side
> tricks.

Even if it did build the compiler for each tool it may not be a problem
if only the last 3 versions had the tools available (for instance).

> Otherwise, I would define a single rust-tools package with
> (outputs '("rustfmt" "clippy" ...)). Perhaps it would help with UX if
> rust-tools itself was hidden, and instead the tools would be exposed
> with simple packages that expose each tool separately, with a symlink or
> similar.

I could see this working nicely.  I think this is just more evidence for
language-environment related documentation.

> I'll see if I can find some time to try this out this week.

Thanks! That would be helpful. It is really painful to have all these
unmerged patches to rust.

Kindly,

John

Message #23 received at 46162 <at> debbugs.gnu.org (full text, mbox):

From: Jakub Kądziołka <kuba <at> kadziolka.net>
To: "John Soo" <jsoo1 <at> asu.edu>
Cc: 46162 <at> debbugs.gnu.org, maxim.cournoyer <at> gmail.com
Subject: Re: bug#46162: [PATCH] staging gnu: Add more tools to rust outputs.
Date: Tue, 16 Feb 2021 17:41:29 +0100

On Tue Feb 16, 2021 at 5:40 PM CET, John Soo wrote:
> Hi Jakub,
>
> Jakub Kądziołka <kuba <at> kadziolka.net> writes:
>
> > I don't think tools beyond rustc and cargo should be included in the
> > main rust package, as this causes them to be built in each step of the
> > bootstrap. I believe a better approach would be to define separate
> > packages for them.
>
> Yeah that would make sense. Have we explored any of the incremental or
> --keep-stage options to speedup the bootstrap?

apteryx mentioned some experiments with those on #mrustc.

Regards,
Jakub Kądziołka

Message #26 received at 46162 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Jakub Kądziołka <kuba <at> kadziolka.net>
Cc: 46162 <at> debbugs.gnu.org, John Soo <jsoo1 <at> asu.edu>
Subject: Re: bug#46162: [PATCH] staging gnu: Add more tools to rust outputs.
Date: Thu, 18 Feb 2021 13:01:09 -0500

Hi,

Jakub Kądziołka <kuba <at> kadziolka.net> writes:

> On Tue Feb 16, 2021 at 5:40 PM CET, John Soo wrote:
>> Hi Jakub,
>>
>> Jakub Kądziołka <kuba <at> kadziolka.net> writes:
>>
>> > I don't think tools beyond rustc and cargo should be included in the
>> > main rust package, as this causes them to be built in each step of the
>> > bootstrap. I believe a better approach would be to define separate
>> > packages for them.
>>
>> Yeah that would make sense. Have we explored any of the incremental or
>> --keep-stage options to speedup the bootstrap?
>
> apteryx mentioned some experiments with those on #mrustc.
>
> Regards,
> Jakub Kądziołka

Those weren't fruitful, but I didn't push it; I think it caused cargo to
fail compiling itself, or its test suite.

Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.