guix-patches
[Top][All Lists]
Advanced

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

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


From: John Soo
Subject: [bug#46162] [PATCH] staging gnu: Add more tools to rust outputs.
Date: Tue, 16 Feb 2021 08:40:20 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

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?

> 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





reply via email to

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