V: windows binary cannot compile hello_world.v

Created on 2 Jul 2019  ·  7Comments  ·  Source: vlang/v

V version: 0.1.11
OS: windows7 64bit

What did you do?
i download https://github.com/vlang/v/releases/download/v0.1.11/v.zip and unzip to
D:\v\1, then I run

cd /d D:\v\1
D:\v\1>v_windows
REPL does not work on Windows yet, sorry!

D:\v\1>cd examples

D:\v\1\examples>..\v_windows D:\v\1\examples\hello_world.v
ATTR =16
ATTR =-1
Looks like you are running V for the first time.
ATTR =-1
V repo not found. Go to https://vlang.io to download V.zip
or install V from source.

D:\v\1\examples>cd ..

D:\v\1>v_windows D:\v\1\examples\hello_world.v
ATTR =16
ATTR =-1
Looks like you are running V for the first time.
ATTR =16
Setting VROOT to "D:\v\1".
coudlnt create file "C:\Users\lutao//.vlang//D:\v\1\examples\hello_world.c"

What did you expect to see?
build a hello_world.exe

What did you see instead?
when run at D:\v\1\exmples, it output some msg and exit.
when run at D:\v\1 ,the problem hang and abort
in windows, the "C:\Users\lutao//.vlang//D:\v\1\examples\hello_world.c" cannot be created, because there is a ":" in the middle of path

Bug

Most helpful comment

@medvednikov the problem is that you are treating Windows as if it was another Unix-like variant. The result it's frustrating for us and for you (I imagine).

First of all, the path separator in Windows is "\", not "/" (please, MinGW-w64 suffices, avoid to introduce dependencies from MSYS/MSYS2 or Cygwin).

Second, forget the concept of "home directory" (like the path above "C:\Users\<user name>//.vlang//examples\hello_world.c"): it was introduced in Windows relatively recently but it doesn't make sense on computers that, for the most part, are owned and operated by a single person.

Use instead, as root directory for the compiler, the directory from which the compiler executable was invoked, which can be retrieved passing NULL as first parameter to the GetModuleFileNameA function in libloaderapi.h
See https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulefilenamea

In so doing, "installing" the compiler it's just decompressing v.zip somewhere.

All 7 comments

even if I remove the disk driver in the path, still got error

D:\v\1>v_windows examples\hello_world.v
ATTR =16
ATTR =16
coudlnt create file "C:\Users\lutao//.vlang//examples\hello_world.c"

why not compile the file under current directory directlly?

if i copy the .v file to the directory that v_windows is in, it can pass compile (a hello_world.c generated at C:\Users\lutao.vlang)but no exe file build

D:\v\1>copy examples\hello_world.v .
已复制         1 个文件。

D:\v\1>v_windows hello_world.v
ATTR =16
ATTR =16

btw, what is meaning of ATTR =16?

I doubt i need a mingw in PATH to build a exe file, need I?
as i didnt occur same error when i build v from source
as https://github.com/vlang/v/issues/834 says

@medvednikov the problem is that you are treating Windows as if it was another Unix-like variant. The result it's frustrating for us and for you (I imagine).

First of all, the path separator in Windows is "\", not "/" (please, MinGW-w64 suffices, avoid to introduce dependencies from MSYS/MSYS2 or Cygwin).

Second, forget the concept of "home directory" (like the path above "C:\Users\<user name>//.vlang//examples\hello_world.c"): it was introduced in Windows relatively recently but it doesn't make sense on computers that, for the most part, are owned and operated by a single person.

Use instead, as root directory for the compiler, the directory from which the compiler executable was invoked, which can be retrieved passing NULL as first parameter to the GetModuleFileNameA function in libloaderapi.h
See https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulefilenamea

In so doing, "installing" the compiler it's just decompressing v.zip somewhere.

@MaD70 you are mostly right except calling -A function, this will break things with non-latin characters in path and give us encodings nightmare from windows 98 :)

@vitalyster you are right. It's a long while that I don't program with Windows APIs directly.
The widestring version (UNICODE) GetModuleFileNameW would be better.

This was fixed today.

Was this page helpful?
0 / 5 - 0 ratings