v
v copied to clipboard
vlang
`-native` option does not compile the same as regular V
OS: linux, "Manjaro Linux"
Processor: 32 cpus, 64bit, little endian, AMD Ryzen 9 5950X 16-Core Processor
CC version: cc (GCC) 11.1.0
getwd: /home/jamie
vmodules: /home/jamie/.vmodules
vroot: /home/jamie/git/v
vexe: /home/jamie/git/v/v
vexe mtime: 2021-09-06 01:01:13
is vroot writable: true
is vmodules writable: true
V full version: V 0.2.4 1a555ab.6084c0f
Git version: git version 2.33.0
Git vroot status: 0.2.4-40-g6084c0fc (3 commit(s) behind V master)
.git/config present: true
thirdparty/tcc status: thirdparty-linux-amd64 333c14de
What did you do?
- clone github.com/vlang/coreutils
- cd coreutils
- make
- v -o bin/true src/true
What did you expect to see?
Since I know -native is not fully supported, yet, I expected a message about something not being implemented.
What did you see instead?
jamie@5950x coreutils]$ v -o bin src/true
builder error: '/home/jamie/git/coreutils/bin' is a directory
[jamie@5950x coreutils]$
That is a very interesting observation 🤔 .
With v -b native src/true/true.v, I get:
v -b native src/true/ produces:
scanner error: src/true/ is not a file
v src/true/ compiles fine
v -o bin src/true produces:
builder error: '/v/coreutils/main/bin' is a directory
which is I think normal, since bin/ is indeed a directory, not a file.
v -o bin/true src/true also works.
v -b native -o bin/true src/true produces:
scanner error: src/true is not a file
I'll investigate further why the backends have different behaviour for the -o option. To me that should behave the same, only the output format may change between the backends 🤔 .
I don't think it's the -o option that's the problem. V without -native accepts a directory and just compiles all the files in it. Adding -native only works if you give it a single file.
The modules used by this true program are not yet supported by the native backend. i pushed this PR today: https://github.com/vlang/v/pull/11426
which makes the import statement work (and fail with proper error if the module uses something not handled by the native backend) instead of just failing on the import statement.
will come back to this issue after having it merged and i'll implement some more stuff to report better errors
