[PATCH] staging gnu: Add more tools to rust outputs.

Open

Details

3 participants

John Soo
Jakub K?dzio?ka
Maxim Cournoyer

Owner: unassigned

Submitted by: John Soo

Severity: normal

John Soo wrote on 28 Jan 2021 23:00

Recipients:(address . guix-patches@gnu.org)

Message-ID:87eei4k9hn.fsf@asu.edu

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

Attachment: 0001-gnu-Add-more-tools-to-rust-outputs.patch

John Soo wrote on 29 Jan 2021 00:29

Recipients:(address . 46162@debbugs.gnu.org)

Message-ID:875z3gk5cd.fsf@asu.edu

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

- John

Attachment: 0001-gnu-Add-more-tools-to-rust-outputs.patch

John Soo wrote on 15 Feb 2021 17:13

Recipients:(address . 46162@debbugs.gnu.org)

Message-ID:87ft1xwbqh.fsf@asu.edu

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

Attachment: 0001-gnu-Add-more-tools-to-rust-outputs.patch

John Soo wrote on 15 Feb 2021 19:09

Recipients:(address . 46162@debbugs.gnu.org)(address . kuba@kadziolka.net)

Message-ID:877dn9w6cq.fsf_-_@asu.edu

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

Jakub K?dzio?ka wrote on 16 Feb 2021 00:41

Recipients:

Message-ID:C9AI2TKPWQ4B.2SAN12EWNA247@gravity

On Mon Feb 15, 2021 at 7:09 PM CET, John Soo wrote:

Toggle quote (7 lines)

> 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

John Soo wrote on 16 Feb 2021 17:40

Recipients:(name . Jakub K?dzio?ka)(address . kuba@kadziolka.net)(address . 46162@debbugs.gnu.org)

Message-ID:87wnv80xvv.fsf@asu.edu

Hi Jakub,

Jakub K?dzio?ka <kuba@kadziolka.net> writes:

Toggle quote (5 lines)

> 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?

Toggle quote (12 lines)> 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).

Toggle quote (6 lines)

> 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.

Toggle quote (2 lines)

> 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

Jakub K?dzio?ka wrote on 16 Feb 2021 17:41

Recipients:(name . John Soo)(address . jsoo1@asu.edu)

Message-ID:C9B3S080FBJ3.1CPQDB4088F2L@gravity

On Tue Feb 16, 2021 at 5:40 PM CET, John Soo wrote:

Toggle quote (12 lines)> Hi Jakub,
>
> Jakub K?dzio?ka <kuba@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

Maxim Cournoyer wrote on 18 Feb 2021 19:01

Recipients:(name . Jakub K?dzio?ka)(address . kuba@kadziolka.net)

Message-ID:87wnv5uufu.fsf@gmail.com

Hi,

Jakub K?dzio?ka <kuba@kadziolka.net> writes:

Toggle quote (18 lines)> On Tue Feb 16, 2021 at 5:40 PM CET, John Soo wrote:
>> Hi Jakub,
>>
>> Jakub K?dzio?ka <kuba@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

Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 46162@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 46162

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date