GNU bug report logs - #43821
Vlang REPL broken

Previous Next

To reply to this bug, email your comments to 43821 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: bug-guix <at> gnu.org, Ryan Prior <rprior <at> protonmail.com>
Subject: Vlang REPL broken
Date: Tue, 06 Oct 2020 01:30:50 +0200

[Message part 1 (text/plain, inline)]

Guix,

Commit 84fa2ced47e16de66674ca169845a6f08cb5ef6c broke the vlang 
REPL (‘v repl’ or simply ‘v’ without arguments) in a new way:

[Message part 2 (text/plain, inline)]

~ λ v
For usage information, quit V REPL and run `v help`
cannot compile 
`/gnu/store/zf80y1bfdvpc6s3lrs33vlc6d1d745la-vlang-0.1.29/bin/cmd/tools/vrepl.v`: 
builder error: folder 
`/gnu/store/zf80y1bfdvpc6s3lrs33vlc6d1d745la-vlang-0.1.29/bin/cmd/tools` 
is not writable

[Message part 3 (text/plain, inline)]

The compiler works fine.

The REPL didn't work before so this isn't a regression per se, but 
it still needs to be fixed.

[Message part 4 (text/plain, inline)]

λ guix install vlang
The following package will be downgraded:
  vlang 0.1.29 → 0.1.27
[...]
~ λ v
For usage information, quit V REPL using `exit` and use `v help`
cannot compile 
‘/gnu/store/1f5nzwf1jhn5iikhfpxjdxcbmj24zdf5-vlang-0.1.27/bin/cmd/tools/vrepl.v: 
/gnu/store/1f5nzwf1jhn5iikhfpxjdxcbmj24zdf5-vlang-0.1.27/bin/cmd/tools/vrepl.v:64:1: 
warning: function `repl_help` in module main cannot be declared 
public 
  62 | }
  63 | 
  64 | pub fn repl_help() {
     | ~~~~~~~~~~~~~~~~~~
  65 |     println(util.full_v_version())
  66 |     println('
/gnu/store/1f5nzwf1jhn5iikhfpxjdxcbmj24zdf5-vlang-0.1.27/bin/cmd/tools/vrepl.v:73:1: 
warning: function `run_repl` in module main cannot be declared 
public 
  71 | }
  72 | 
  73 | pub fn run_repl(workdir string, vrepl_prefix string) 
  []string {
     | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  74 |     println(util.full_v_version())
  75 |     println('Use Ctrl-C or `exit` to exit')
/gnu/store/1f5nzwf1jhn5iikhfpxjdxcbmj24zdf5-vlang-0.1.27/bin/cmd/tools/vrepl.v:240:1: 
warning: function `rerror` in module main cannot be declared 
public 
 238 | }
 239 | 
 240 | pub fn rerror(s string) {
     | ~~~~~~~~~~~~~~~~~~~~~~~
 241 |     println('V repl error: $s')
 242 |     os.flush()
builder error: C compiler error, while attempting to run: 
-----------------------------------------------------------
cc  -std=gnu11 -Wall -Wextra -Wno-unused-variable 
-Wno-unused-parameter -Wno-unused-result -Wno-unused-function 
-Wno-missing-braces -Wno-unused-label 
-Werror=implicit-function-declaration -o 
"/gnu/store/1f5nzwf1jhn5iikhfpxjdxcbmj24zdf5-vlang-0.1.27/bin/cmd/tools/vrepl" 
"/home/nckx/.cache/v/vrepl.tmp.c"   -lm -lpthread -ldl
-----------------------------------------------------------
Probably your C compiler is missing. 
Please reinstall it, or make it available in your PATH.

On Debian/Ubuntu, run `sudo apt install build-essential`‘

[Message part 5 (text/plain, inline)]

Kind regards,

T G-R

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 43821 <at> debbugs.gnu.org (full text, mbox):

From: Ryan Prior <rprior <at> protonmail.com>
To: 43821 <at> debbugs.gnu.org
Subject: [PATCH 0/1] Progress improving vlang package
Date: Tue, 06 Oct 2020 05:03:34 +0000

One of the challenges of packaging v is that its install script assumes that you'll install it in a mutable folder, and uses that assumption to lazily build the included tools as they're needed instead of eagerly building everything up-front.

There's an included command for eagerly building these tools, which we should invoke in order to make sure that the repl &c are available at package installation time and the user won't need write access to the v directory.

This patch presents progress in that direction, but it has a ways to go. Like golang, the v build system resolves dependencies on git repos as it goes, so once I run `v build-tools` it wants to go and fetch the vlang/markdown repo. So we'll probably need to package that ahead of time.

That, however, raises the chicken-and-egg problem. Do we create a vlang-bootstrap package that we use to compile the deps (like vlang/markdown) and then in turn use those as inputs to the "real" v package which also builds all the tools? Do we include those deps as explicit source-only native-inputs of the v package? I don't know which strategy I prefer yet, I'd be interested to hear any input from others.

So in the spirit of progress here's my work-in-progress patch!

Cheers,
Ryan

Ryan Prior (1):
  gnu: vlang: Build included tools at package time.

 gnu/packages/vlang.scm | 25 ++++++++++++++++++-------
 1 file changed, 18 insertions(+), 7 deletions(-)

-- 
2.17.1

Message #11 received at 43821 <at> debbugs.gnu.org (full text, mbox):

From: Ryan Prior <rprior <at> protonmail.com>
To: 43821 <at> debbugs.gnu.org
Subject: [PATCH 1/1] gnu: vlang: Build included tools at package time.
Date: Tue, 06 Oct 2020 05:03:41 +0000

* gnu/packages/vlang.scm (vlang): Updates build stages.
  - Moves the cc-patching logic out of check into an explicit "patch-cc" stage
  - Adds "build-tools" stage to pre-build the included tools
---
 gnu/packages/vlang.scm | 25 ++++++++++++++++++-------
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/gnu/packages/vlang.scm b/gnu/packages/vlang.scm
index 6f6aa79ce5..47060934d4 100644
--- a/gnu/packages/vlang.scm
+++ b/gnu/packages/vlang.scm
@@ -22,6 +22,7 @@
   #:use-module (gnu packages node)
   #:use-module (gnu packages sqlite)
   #:use-module (gnu packages tls)
+  #:use-module (gnu packages version-control)
   #:use-module (gnu packages xorg)
   #:use-module (guix build-system gnu)
   #:use-module (guix git-download)
@@ -61,6 +62,18 @@
               (("rm -rf") "true")
               (("v self") "v -cc gcc cmd/v"))
             #t))
+        (add-after 'build 'patch-cc
+          (lambda _
+            (let* ((bin "tmp/bin")
+                   (gcc (which "gcc")))
+              (mkdir-p bin)
+              (symlink gcc (string-append bin "/cc"))
+              (setenv "PATH" (string-append bin ":" (getenv "PATH")))
+              #t)))
+        (add-after 'patch-cc 'build-tools
+          (lambda _
+            (invoke "./v" "build-tools" "-v")
+            #t))
         (add-before 'check 'delete-failing-tests
           ;; XXX As always, these should eventually be fixed and run.
           (lambda _
@@ -74,13 +87,8 @@
             #t))
         (replace 'check
           (lambda* (#:key tests? #:allow-other-keys)
-            (let* ((bin "tmp/bin")
-                   (gcc (which "gcc")))
-              (when tests?
-                (mkdir-p bin)
-                (symlink gcc (string-append bin "/cc"))
-                (setenv "PATH" (string-append bin ":" (getenv "PATH")))
-                (invoke "./v" "test-fixed")))
+            (when tests?
+              (invoke "./v" "test-fixed"))
             #t))
         (replace 'install
           (lambda _
@@ -121,6 +129,9 @@
             (sha256
              (base32 "052gp5q2k31r3lci3rx4k0vy0vjdjva64xvrbbihn8lgmw63lc9f")))))
 
+      ;; For build-tools
+      ("git" ,git)
+
       ;; For the tests.
       ("libx11" ,libx11)
       ("node" ,node)
-- 
2.17.1

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.