[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