GNU bug report logs -
#52107
rust-analyzer shipped broken without rust-src
Previous Next
To reply to this bug, email your comments to 52107 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#52107
; Package
guix
.
(Thu, 25 Nov 2021 14:54:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Nicholas von Klitzing <nicholas <at> nvk.pm>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Thu, 25 Nov 2021 14:54:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello Guix,
The rust-analyzer package depends on having a local copy of the rust compiler (rustc) source code available in order for it to function.
Currently, neither the rust-analyzer nor the rust package include rust-src, which means rust-analyzer is broken by default.
On non-guix systems the rustc source code is usually installed using `rustup component add rust-src`.
The workaround I'm currently using is to run `guix build --source rust` followed by adding `export RUST_SRC_PATH=/home/$user/rustc-$version-src/library` to ~/.profile following every rust upgrade.
rust-analyzer is a crucial tool for many rust developers, so this experience should definitely be improved or at least documented.
I am not very familiar with guix and therefore cannot recommend a good way to solve this.
What would possible solutions to this issue be?
Kind regards,
Nicholas
Information forwarded
to
bug-guix <at> gnu.org
:
bug#52107
; Package
guix
.
(Fri, 26 Nov 2021 09:43:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 52107 <at> debbugs.gnu.org (full text, mbox):
Just to get the ball rolling, here is a possible idea.
It might makes sense to add an additional output to the rust package `src` and then require this by the rust-analyzer package as `rust:src`.
In the rust-analyzer package we could then copy a thing from `icedove-wayland`:
``
(arguments
'(#:modules ((guix build utils))
#:builder
(begin
(use-modules (guix build utils))
(let* ((bash (assoc-ref %build-inputs "bash"))
(icedove (assoc-ref %build-inputs "icedove"))
(out (assoc-ref %outputs "out"))
(exe (string-append out "/bin/icedove")))
(mkdir-p (dirname exe))
(call-with-output-file exe
(lambda (port)
(format port "#!~a
;; This style of overriding environment variables could be used for
;; RUST_SRC_PATH, although I am not sure if this is the idiomatic
;; way to do it.
MOZ_ENABLE_WAYLAND=1 exec ~a $@"
(string-append bash "/bin/bash")
(string-append icedove "/bin/icedove"))))
...
((icedove) out))
#t))))
``
Information forwarded
to
bug-guix <at> gnu.org
:
bug#52107
; Package
guix
.
(Fri, 26 Nov 2021 14:22:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 52107 <at> debbugs.gnu.org (full text, mbox):
Nicholas von Klitzing schreef op vr 26-11-2021 om 09:42 [+0000]:
> Just to get the ball rolling, here is a possible idea.
>
> It might makes sense to add an additional output to the rust package
> `src` and then require this by the rust-analyzer package as
> `rust:src`.
I'd use a native-search-path instead of a wrapper setting the
environment variable, such that rust-analyzer can be used with any
version of rust and the user can override the source code used.
> In the rust-analyzer package we could then copy a thing from
> `icedove-wayland`:
> [
> ...] (call-with-output-file exe
> (lambda (port)
> (format port "#!~a
> ;; This style of overriding environment variables could be used for
> ;; RUST_SRC_PATH, although I am not sure if this is the idiomatic
> ;; way to do it.
> MOZ_ENABLE_WAYLAND=1 exec ~a $@"
'wrap-program' could be used here, instead of manually making shell
scripts.
Greetings,
Maxime
Information forwarded
to
bug-guix <at> gnu.org
:
bug#52107
; Package
guix
.
(Fri, 26 Nov 2021 17:41:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 52107 <at> debbugs.gnu.org (full text, mbox):
That's definitely a much better solution.
I'm having trouble finding documentation about both native-search-paths and wrap-program, so let me know if I understand your suggestions and how to apply them correctly.
The rust-1.18 package has a native-search-paths declaration:
``
(native-search-paths
(list (search-path-specification
(variable "C_INCLUDE_PATH")
(files '("include")))
(search-path-specification
(variable "CPLUS_INCLUDE_PATH")
(files '("include/c++" "include")))
(search-path-specification
(variable "LIBRARY_PATH")
(files '("lib" "lib64")))
;; Do you mean add something along the lines of
;; this to every rust-xx package?
(search-path-specification
(variable "RUST_SRC_PATH")
(files '("library"))))) ;; I'm not sure what arguments this takes
``
The directory structure of the rust repository, changes over time, so the paths would need to be adjusted depending on the version. Would I also need to add an additional build step to copy over the source and register it as an output?
And for the rust-analyzer package we then add something along the lines of?
``
(add-after
'install 'wrap-rust-analyzer
(lambda* (#:key inputs outputs #:allow-other-keys)
(let ((out (assoc-ref outputs "out"))
(rust-src-path (getenv "RUST_SRC_PATH")))
(wrap-program (string-append out "/bin/rust-analyzer")
`("RUST_SRC_PATH" ":" prefix (,rust-src-path))))
#t))
``
I'd appreciate your feedback, since I'm mostly clueless :)
Kind regards,
Nicholas
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, November 26th, 2021 at 2:21 PM, Maxime Devos <maximedevos <at> telenet.be> wrote:
> Nicholas von Klitzing schreef op vr 26-11-2021 om 09:42 [+0000]:
>
> > Just to get the ball rolling, here is a possible idea.
> >
> > It might makes sense to add an additional output to the rust package
> >
> > `src` and then require this by the rust-analyzer package as
> >
> > `rust:src`.
>
> I'd use a native-search-path instead of a wrapper setting the
>
> environment variable, such that rust-analyzer can be used with any
>
> version of rust and the user can override the source code used.
>
> > In the rust-analyzer package we could then copy a thing from
> >
> > `icedove-wayland`:
> >
> > [
> >
> > ...] (call-with-output-file exe
> >
> > (lambda (port)
> >
> > (format port "#!~a
> >
> > ;; This style of overriding environment variables could be used for
> >
> > ;; RUST_SRC_PATH, although I am not sure if this is the idiomatic
> >
> > ;; way to do it.
> >
> > MOZ_ENABLE_WAYLAND=1 exec ~a $@"
>
> 'wrap-program' could be used here, instead of manually making shell
>
> scripts.
>
> Greetings,
>
> Maxime
Information forwarded
to
bug-guix <at> gnu.org
:
bug#52107
; Package
guix
.
(Fri, 26 Nov 2021 18:08:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 52107 <at> debbugs.gnu.org (full text, mbox):
Nicholas von Klitzing schreef op vr 26-11-2021 om 17:40 [+0000]:
> That's definitely a much better solution.
>
> I'm having trouble finding documentation about both native-search-
> paths and wrap-program, so let me know if I understand your
> suggestions and how to apply them correctly.
>
> The rust-1.18 package has a native-search-paths declaration:
> ``
> (native-search-paths
> (list [...]
> ;; Do you mean add something along the lines of
> ;; this to every rust-xx package?
> (search-path-specification
> (variable "RUST_SRC_PATH")
> (files '("library"))))) ;; I'm not sure what arguments
The package that is using RUST_SRC_PATH is rust-analyzer, not
rust <at> some-version. As such, the search path should be added to rust-
analyzer, not rust.
Search paths are added to the consumer, not the producer, as I've seen
it described somewhere.
Probably (separator #f) should be added, because I don't think rust-
analyzer supports using source code of multiple rusts at once.
> this takes
>
> ``
> The directory structure of the rust repository, changes over time, so
> the paths would need to be adjusted depending on the version. Would I
> also need to add an additional build step to copy over the source and
> register it as an output?
The idea is to copy the unpacked source code to some output (let's call
it "source"). We would have to choose some subdirectory. Looking at the
package definition of rust-analyzer, it appears to like
‘lib/rustlib/src/rust’, so the source code could be copied to (string-
append #$output:src "/lib/rustlib/src/rust").
If that directory is used, files would be set to
'("lib/rustlib/src/rust").
> And for the rust-analyzer package we then add something along the
> lines of?
>
> ``
> (add-after
> 'install 'wrap-rust-analyzer
> (lambda* (#:key inputs outputs #:allow-other-keys)
> (let ((out (assoc-ref outputs "out"))
> (rust-src-path (getenv "RUST_SRC_PATH")))
> (wrap-program (string-append out "/bin/rust-
> analyzer")
> `("RUST_SRC_PATH" ":" prefix (,rust-src-path))))
> #t))
> ``
Both wrapping and a search path wouldn't make much sense: the wrapping
would effectively override the search path, basically hard-coding the
source code used. Either go for a wrapper, a search path, or a wrapper
only setting the environment variable if it wasn't set already (*)(such
that the wrapper only sets a default).
(*) see docstring of wrap-program for how to do this, and whether it is
actually possible.
If you go for a wrapper instead of native-search-path, then
RUST_SRC_PATH would be unset in the build environment, so the (getenv
...) would need to be replaced with (search-input-directory (or native-
inputs inputs) "lib/rustlib/src/rust")).
Greetings,
Maxime
This bug report was last modified 3 years and 4 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.