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

  • Open
  • quality assurance status badge
Details
3 participants
  • John Soo
  • Jakub K?dzio?ka
  • Maxim Cournoyer
Owner
unassigned
Submitted by
John Soo
Severity
normal
J
J
John Soo wrote on 28 Jan 2021 23:00
(address . guix-patches@gnu.org)
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
-----BEGIN PGP SIGNATURE-----

iQJCBAEBCAAsFiEEWhWPr0BqdIqBqdxOT0N6drRIojsFAmATM/QOHGpzb28xQGFz
dS5lZHUACgkQT0N6drRIojtLBBAA0tIdWUdry9+VKn67NlIMjvxOAvN8krw9VSzd
z5+APOhmtscN956V0lkBKgc1ME1nA+iE643lnmKfK+DWnr621afd52JJAMrmG4xv
Ds7XOGGfANxHDRNqxqrEPZUEN1vL7eUC0z1hsl11hCOkjL6Ka56/DUIerPViOMLW
AZEPBhx6eDsKPLckRFPGWZUbB/O6ejLtpmou38IeYGAMlgJVop7Uk4JGzo6h9ZHD
c2bkoEofi8DgtBoYuZ4RmCSGFw1JrqIFnZtXzrqqSdjaFA/GBV5ozGRtfXLlfxZN
qB4ZEvgJRnvGOWELKJVuyk9oeD4BqpYYva3Xqf3zlp3jCNHLa17ZC1EKlyt/WaOm
r7EorYpJdIuc1kpAwVzz3ns/LatdmnMZX3aWyifAU6jJWDH8xl1TPAiKTo8hRil/
RhEtqfUBegV/qIn/hdidKWXEnWlEtEgU3gRl1KTrZ5+f/hy2eSj3T7RFPkdQmH3i
qhyF8HFGmlejjX2IXN5/UB0bVBWVnR3PF7cjAE+D3yJdJ/PwGVetPlydsL6nFISL
CVhlDsjFiNiv6Ry1evYEI9NYhl+jLTRt4eygSk9iP7zFFq0bk3aib6F2VX83gdXM
fVceT5S+SiE32w7OYhn8A0+4+yywKciasJZTV1zBP86YYGb993Y0bvctKujiD33p
rEOqDQA=
=V2V8
-----END PGP SIGNATURE-----

J
J
John Soo wrote on 29 Jan 2021 00:29
(address . 46162@debbugs.gnu.org)
875z3gk5cd.fsf@asu.edu
Here is an edited patch. I had rebased incorrectly, my apologies.

- John
-----BEGIN PGP SIGNATURE-----

iQJCBAEBCAAsFiEEWhWPr0BqdIqBqdxOT0N6drRIojsFAmATSPIOHGpzb28xQGFz
dS5lZHUACgkQT0N6drRIojthdw//b0ZQ+OGlEdBbInkATFXl0e+AMw77cttcJO2y
iYE95ZiK2H7HprM36x9cdTTZfXyGnOp1rqe3G/U2245U7TvaSymqlPWsSGEIZ2Ut
gVSrFFOulF9DwsUuBPvCxcPHFvHLZYTQtmcp8fUkHvVYswOhwkZ9ir11bkfffpXw
zjzEWeZDVhN8lv+iqvHSkX8qrOjn8YNX3vvI71urbtFuLc5K3EQH01ZIlso6v290
rLc7hGqJW+Y6dh4FmEorVDvCbr/EWo4AJkTic4odcew6PTb7XcFZi+VqQdyW6IxS
d8eGghlOzi6zi+X2t4n84nZWCgdjjaG+qsj60oaMC3qTUAH87CRy/EObCHSckRcv
7CZWjyKrXH7ZTQ3p0me+HMc7lLUGWS9DiMZxYGXHColWNYDtt73hlyVE4fSkRlXk
GZsDPDtaabim9hs9sBHwQhxNYWvK3Stx722bhKC8i7KKfXOaVvhNdcpJM0aBE+fD
Aj4qMuN5O4PejOaWt0pR1hzrucd4THnzNTN1dzQUc1hVa1P1HRCJlNGddg/NlT7p
I2SYc6aDbE+GBTo3mRibYMBdV2zhqJNw1GRBInnKdk/bFoTu/F/1WSTk9QMP1ehK
wFOr8MLcG+3yiq2zl6svXVpXVjLyM0NmVvRmjiHINB4E8d3tvcTVkILk+vtAa+Z/
XtLziOY=
=CwBZ
-----END PGP SIGNATURE-----

J
J
John Soo wrote on 15 Feb 2021 17:13
(address . 46162@debbugs.gnu.org)
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
J
J
John Soo wrote on 15 Feb 2021 19:09
(address . 46162@debbugs.gnu.org)(address . kuba@kadziolka.net)
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
J
J
Jakub K?dzio?ka wrote on 16 Feb 2021 00:41
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
J
J
John Soo wrote on 16 Feb 2021 17:40
(name . Jakub K?dzio?ka)(address . kuba@kadziolka.net)(address . 46162@debbugs.gnu.org)
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
J
J
Jakub K?dzio?ka wrote on 16 Feb 2021 17:41
(name . John Soo)(address . jsoo1@asu.edu)
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
M
M
Maxim Cournoyer wrote on 18 Feb 2021 19:01
(name . Jakub K?dzio?ka)(address . kuba@kadziolka.net)
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
?