Install Vesta

Vesta is in alpha. The source is public and can be built today; prepared binaries will arrive with the first tagged release.

In development. There are no published binaries yet, so for now the way to try Vesta is to build it from source.

Once they exist, the packages for Windows, Linux and macOS will appear here alongside their checksum and signature.

No binaries does not mean unusable. On Windows the project even builds its own installer with a single command.

1. Dependencies

PlatformCommand
Debian and Ubuntusudo apt install build-essential cmake libssl-dev
Arch Linuxsudo pacman -S base-devel cmake openssl
macOSbrew install cmake openssl
WindowsTDM-GCC-64 (or MinGW) and CMake, plus OpenSSL

Keystone, Capstone and LibPEparse ship as submodules and clone themselves. Nothing else is required.

2. Clone and build

git clone --recursive https://github.com/vesta-lang/vesta.git
cd vesta

cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build -j

On Windows with TDM-GCC you need to ask for the MinGW generator:

cmake -G "MinGW Makefiles" -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build -j

With CMake 4 or newer you may need to add -DCMAKE_POLICY_VERSION_MINIMUM=3.5, because one of the submodules declares a minimum older than that version accepts.

The resulting executable is build/vm. Once installed it is called vesta.

3. Check that it works

./build/vm --version

4. Your first program

Save this as hello.vx:

site/snippets/hello.vx
i32 main() {
    println("Hello from Vesta ${1 + 1}!");
    return 0;
}

Then build it, from the repository root (see the note on the standard library below):

./build/vm --vx hello.vx -o hello
./build/vm --run hello.velb

The same source can be compiled into a standalone native executable, without the virtual machine:

./build/vm --vx hello.vx -m aot -o hello
./hello

There is no make install. Project packaging is Windows-only today, so on Linux and macOS installing means copying files by hand. It is four commands.

Copying the binary alone is not enough. The compiler resolves the standard library, the native plugins and the preprocessor headers relative to its own location, so they have to travel with it.

sudo mkdir -p /usr/local/lib/vesta
sudo cp build/vm            /usr/local/lib/vesta/vesta
sudo cp -r stdlib           /usr/local/lib/vesta/
sudo cp -r preprocessor/include_lib /usr/local/lib/vesta/

That leaves a layout which satisfies all three lookups at once:

/usr/local/lib/vesta/
    vesta              the compiler
    stdlib/vx/         standard library modules
    stdlib/native/     native plugins
    include_lib/       preprocessor headers

And to call it from anywhere, a symbolic link:

sudo ln -s /usr/local/lib/vesta/vesta /usr/local/bin/vesta
vesta --version

The link works because on Linux the compiler finds out where it lives by reading /proc/self/exe, which resolves the link and returns the real path.

On macOS, avoid the symbolic link. There the executable path is obtained differently and may come back as the link itself, which would send the compiler looking for its resources in /usr/local/bin. Add the directory to your PATH instead:

echo 'export PATH="/usr/local/lib/vesta:$PATH"' >> ~/.zshrc

This is the easiest route on Windows. The project builds its own installer through CMake, and downloads NSIS by itself if you do not have it.

cmake --build build --target installer

That leaves a VestaVM-<version>-win64.exe which takes care of everything: it copies the standard library and the native plugins next to the executable, adds Vesta to the PATH and creates the Start Menu shortcut.

From then on vesta works from any shell and finds its resources by itself. No environment variables, no working from one particular folder.

vesta --version

If you would rather not install anything, there is a portable ZIP with the same file layout:

cmake --build build --target installer-zip
Choosing components at install time

The installer lets you tick and untick what gets installed. The defaults are right for most people; this table is only there if you want to fine-tune.

ComponentWhat it contains
coreThe compiler, the runtime and the link-time libraries. Required.
stdlibThe standard library and the native plugins.
lspThe language server, for editors.
examplesThe example programs.
toolsProject utilities.
sdkHeaders and libraries for embedding Vesta or writing plugins.

One warning only: do not untick stdlib unless you know what you are doing. Without it the compiler still starts, but no program that imports a standard library module will ever build.

How the compiler finds its resources

This matters if you build from source or install by hand. With the Windows installer you do not need to know any of it: it puts the files where the compiler expects them and everything just works.

This is the most common reason a manual install fails. The compiler does not carry its resources inside: it looks for them on disk, and not all of them are looked up the same way.

ResourceWhat it isWhere it is searched
stdlib/vxStandard library modulesVX_STDLIB_DIR, then relative to the working directory, then to the executable
include_libVPP preprocessor headersRelative to the executable
stdlib/nativeNative plugins (I/O, math)Only relative to the executable

The last row is the surprising one: native plugins check neither the environment variable nor the working directory. That is why copying just the binary into /usr/local/bin leaves you with a compiler that starts up and then fails as soon as a program does any input or output.

For stdlib/vx, the full order is:

  1. The VX_STDLIB_DIR variable, if set.
  2. Relative to the working directory: stdlib/vx, ../stdlib/vx or ../../stdlib/vx.
  3. Relative to the executable: <dir>/stdlib/vx or <dir>/../stdlib/vx.

That is why the examples above run from the repository root: build/vm has no stdlib/ beside it, and works through the second rule. Move to another directory and it stops working.

There is also a VX_PATH variable, shaped like PATH, to add directories where your own modules are looked up.

What to expect from an alpha

The language, the compiler, the virtual machine and the JIT work and are tested. Some parts are under active development, and they are marked as such wherever they appear in this documentation.

It is not recommended for production yet, and the syntax may change between versions. If you hit a bug, the place to report it is the project repository.