C => V source code translator.

Demo Video: Translating DOOM from C to V, building and running it.

https://www.youtube.com/watch?v=6oXrz3oRoEg

v .

... or if you want to debug c2v behaviour:

v -d trace_verbose .

No dependencies other than a clang binary.

c2v accepts the following arguments:

-keep_ast           keep ast files
-print_tree         print the entire tree
-skip_comments      output no comments
-split_files        write one V file per original source file (see below)

c2v file.c

This will generate file.v.

c2v project

This will translate each C file in the project directory.

c2v -split_files file.c

This translates file.c into one V file per original source file, in the output_dirname folder: code that #line directives attribute to src/btree.c goes to btree.v, declarations of a header util.h to util_h.v, initialized globals to 0_globals.v (V needs them before their uses), and the rest to file.v. For an amalgamation such as SQLite's sqlite3.c (built with --linemacros), this gives V sources organized like the original ones.

project/   ==>  project/
  a.c              a.c
  foo.c            a.v
                   foo.c
		   foo.v

You may need to run translated code with v -translated file.v until early 2023.

C2V also translates C++. examples/doom3 has the project files and step by step instructions for translating the Doom 3 engine and game (dhewm3) to V, building the result and running it.

C2V can also generate V wrappers on top of C libraries.

c2v wrapper file.c

C2V is using Clang's AST to generate V. This allowed us to avoid writing a C parser.

In order to avoid LLVM dependencies/C++ complexity, C2V parses AST generated by the clang binary.

C2V supports reading from a project configuration file named c2v.toml, located in one of these places, in this order:

1. if C2V_CONFIG is set, it should contain the c2v.toml path.
2. the project folder (the last folder passed to c2v) + /c2v.toml
3. the project folder (the folder of the file that is last passed to c2v) + /c2v.toml

That file has the following format:

[project]
uses_sdl = true
output_dirname = "c2v_out.dir"
additional_flags = "-I. -I.. -I../.."

["info.c"]
additional_flags = "-I/some/folder/used/only/for/that/specific/file"

In the above: uses_sdl is a boolean, that defaults to false. When it is true, c2v will append the result of sdl2-config --cflags to additional_flags . output_dirname is a string, that defaults to c2v_output. c2v will create that folder, if it does not exist, and it will put all the translated .v files there. additional_flags is a string, that will be passed verbatim to the clang parser for each .c file. It can be used to pass additional -I flags, that are specific to your project, so that clang can find all the headers needed by that project. pkg_config is a list of pkg-config package names of external C libraries (e.g. ["sdl2", "openal"]). Their --cflags are added to additional_flags, and the generated V code links them with #pkgconfig. uses_sdl = true is a shorthand for pkg_config = ["sdl2"]. link_flags is a string of extra C linker flags for the generated V code, e.g. "-L/opt/homebrew/opt/openal-soft/lib -lopenal". skip_comments = true is the same as the -skip_comments argument, and split_files = true the same as -split_files. module_name is the V module of the translated code (default main). Another name makes a library importable: its declarations are public, and the C functions it calls are declared under private aliases (C.c2v_localtime_r), so that they cannot conflict with the declarations of other modules.

Declarations from system headers (libc, POSIX and third party libraries) are not translated. c2v reads their types, record layouts and enum constants from Clang's AST, and the generated code uses them through V's C interop.

Note: all these are global to the project.

The c2v.toml configuration file also supports file specific overrides, for the additional_flags option, just put them in their own sections, titled as the file name.