Xmake is a lightweight cross-platform build utility based on Lua.
It is very lightweight and has no dependencies because it has a built-in Lua runtime.
It uses xmake.lua to maintain project builds and its configuration syntax is very simple and readable.
We can use it to build project directly like Make/Ninja, or generate project files like CMake/Meson, and it also has a built-in package management system to help users solve the integrated use of C/C++ dependent libraries.
Xmake = Build backend + Project Generator + Package Manager + [Remote|Distributed] Build + Cache
Although not very precise, we can still understand Xmake in the following way:
Xmake ≈ Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache
Windows’ long path limitation has always been a big problem. Projects that are nested too deeply may fail when reading or writing files, which affects xmake’s usability and experience.
Although xmake has provided various measures to avoid this problem, it still suffers from some limitations occasionally. In this release, we have improved the installer by providing an installation option that lets you selectively enable long path support.
This requires administrator privileges, as it requires a registry write.
WriteRegDWORD ${HKLM} "SYSTEM\CurrentControlSet\Control\FileSystem" "LongPathsEnabled" 1
Users can decide for themselves, whether they need to turn it on or not.
Thanks to @A2va for the contribution.
Added support for OpenSUSE’s zypper package manager, which can be automatically downloaded and installed directly from zypper, and integrates with the packages it provides.
Thanks to @iphelf for his contribution.
add_requires("zypper::libsfml2 2.5")
Some third-party packages, which are not maintained by cmake, just provide the vcproj project file, and if we make it into a package, we need to use the tools.msbuild
module to compile and install it.
But if the vs version of vcproj is very old, we need to upgrade it, otherwise the compilation will fail.
So we have improved the tools.msbuild module to provide automatic vcproj upgrades by specifying the vcproj/sln files that need to be upgraded.
package("test")
on_install(function (package)
import("package.tools.msbuild").build(package, configs, {upgrade={"wolfssl64.sln", "wolfssl.vcxproj"}}))
end)
Xmake is a lightweight cross-platform build utility based on Lua.
It is very lightweight and has no dependencies because it has a built-in Lua runtime.
It uses xmake.lua to maintain project builds and its configuration syntax is very simple and readable.
We can use it to build project directly like Make/Ninja, or generate project files like CMake/Meson, and it also has a built-in package management system to help users solve the integrated use of C/C++ dependent libraries.
Xmake = Build backend + Project Generator + Package Manager + [Remote|Distributed] Build + Cache
Although not very precise, we can still understand Xmake in the following way:
Xmake ≈ Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache
Xmake has long supported the virtual environment management of packages, and can switch between different package environments through configuration files.
We can customize some package configurations by adding the xmake.lua file in the current directory, and then enter a specific package virtual environment.
add_requires("zlib 1.2.11")
add_requires("python 3.x", "luajit")
$ xrepo env shell
> python --version
> luajit --version
You can also switch environments by importing custom environment configuration files:
$ xrepo env --add /tmp/base.lua
$ xrepo env -b base shell
In the new version, we have made further improvements, allowing Xrepo to temporarily specify the list of environment packages that need to be bound directly on the command line to achieve fast switching without any configuration.
And it supports specifying multiple package environments at the same time.
For example, we want to enter an environment with python 3.0, luajit and cmake, just execute:
$ xrepo env -b "python 3.x,luajit,cmake" shell
[python, luajit, cmake] $ python --version
Python 3.10.6
[python, luajit, cmake] $ cmake --version
cmake version 3.25.3
Xmake will automatically install the relevant dependencies, and then open a new shell environment. There is also a prompt prompt on the left side of the terminal in the new environment.
If we want to exit the current environment, we only need to execute
[python, luajit, cmake] $ xrepo env quit
$
Xmake is a lightweight cross-platform build utility based on Lua.
It is very lightweight and has no dependencies because it has a built-in Lua runtime.
It uses xmake.lua to maintain project builds and its configuration syntax is very simple and readable.
We can use it to build project directly like Make/Ninja, or generate project files like CMake/Meson, and it also has a built-in package management system to help users solve the integrated use of C/C++ dependent libraries.
Xmake = Build backend + Project Generator + Package Manager + [Remote|Distributed] Build + Cache
Although not very precise, we can still understand Xmake in the following way:
Xmake ≈ Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache
Xmake is now fully operational on Haiku systems and we have added a haiku compilation platform to Xmake for compiling code on Haiku systems.
The result is as follows:
Xmake is a lightweight cross-platform build utility based on Lua.
It is very lightweight and has no dependencies because it has a built-in Lua runtime.
It uses xmake.lua to maintain project builds and its configuration syntax is very simple and readable.
We can use it to build project directly like Make/Ninja, or generate project files like CMake/Meson, and it also has a built-in package management system to help users solve the integrated use of C/C++ dependent libraries.
Xmake = Build backend + Project Generator + Package Manager + [Remote|Distributed] Build + Cache
Although not very precise, we can still understand Xmake in the following way:
Xmake ≈ Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache
Through add_requires("iverilog")
configuration, we can automatically pull the iverilog toolchain package, and then use set_toolchains("@iverilog")
to automatically bind the toolchain to compile the project.
add_requires("iverilog")
target("hello")
add_rules("iverilog. binary")
set_toolchains("@iverilog")
add_files("src/*.v")
add_requires("iverilog")
target("hello")
add_rules("iverilog. binary")
set_toolchains("@iverilog")
add_files("src/*.v")
add_defines("TEST")
add_includedirs("inc")
set_languages("v1800-2009")
We can use set_languages("v1800-2009")
to set the language standard for switching Verilog.
Currently supported values and mappings are as follows:
["v1364-1995"] = "-g1995"
["v1364-2001"] = "-g2001"
["v1364-2005"] = "-g2005"
["v1800-2005"] = "-g2005-sv"
["v1800-2009"] = "-g2009"
["v1800-2012"] = "-g2012"
add_requires("iverilog")
target("hello")
add_rules("iverilog. binary")
set_toolchains("@iverilog")
add_files("src/*.v")
add_values("iverilogs.flags", "-DTEST")
$ xmake
check iverilog... iverilog
check vvp... vvp
[50%]: linking.iverilog hello.vvp
[100%]: build ok!
$ xmake run
hello world!
LXT2 INFO: dumpfile hello.vcd opened, ready for output.
src/main.v:6: $finish called at 0 (1s)
More complete examples: iVerilog Examples
Xmake is a lightweight cross-platform build utility based on Lua.
It is very lightweight and has no dependencies because it has a built-in Lua runtime.
It uses xmake.lua to maintain project builds and its configuration syntax is very simple and readable.
We can use it to build project directly like Make/Ninja, or generate project files like CMake/Meson, and it also has a built-in package management system to help users solve the integrated use of C/C++ dependent libraries.
Xmake = Build backend + Project Generator + Package Manager + [Remote|Distributed] Build + Cache
Although not very precise, we can still understand Xmake in the following way:
Xmake ~= Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache
This new feature is intended to enable the integration of specific sub-libraries from a C/C++ package, and is generally used for library component integration in larger packages.
This is because such packages provide a number of sub-libraries, not all of which are required by the user, and linking them all may be problematic.
Although, previous versions were able to support the feature of sublibrary selection, e.g.
add_requires("sfml~foo", {configs = {graphics = true, window = true}})
add_requires("sfml~bar", {configs = {network = true}})
target("foo")
set_kind("binary")
add_packages("sfml~foo")
target("bar")
set_kind("binary")
add_packages("sfml~bar")
This is done by custom configuration of each package, but there are some problems with this approach.
sfml~foo
and sfml~bar
will be installed repeatedly as two separate packages, taking up double the disk spacesfml~foo
and sfml~bar
, there will be link conflictsThe impact of double-compilation and disk usage can be very high for very large package integrations such as boost, and can even lead to more than N times the disk usage if there are a large number of sub-library combinations.
To solve this problem, Xmake has added a package component mode, which offers some of the following benefits.
For more background details see: #2636
For the user, using package components is very convenient because the user is not required to maintain the package, as long as the package is used, it is configured with the relevant set of components and we can quickly integrate and use it, e.g.
add_requires("sfml")
target("foo")
set_kind("binary")
add_packages("sfml", {components = "graphics"})
target("bar")
set_kind("binary")
add_packages("sfml", {components = "network"})