GNU bug report logs -
#46162
[PATCH] staging gnu: Add more tools to rust outputs.
Previous Next
Full log
Message #20 received at 46162 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 4 years and 117 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.