xmake is a lightweight cross-platform build tool based on Lua. It uses xmake.lua to maintain project builds. Compared with makefile/CMakeLists.txt, the configuration syntax is more Concise and intuitive, very friendly to novices, can get started quickly in a short time, allowing users to focus more on the actual project development.
In this new version, we have made full platform support for the Intel series of C++ and Fortran compilers, and improved the Wasm tool chain support added in the previous version, and also supported the Qt SDK for Wasm.
In addition, we have also upgraded luajit to the latest v2.1 version. In terms of cross-platform, xmake has also made great improvements and added support for mips64 architecture.
On this version, we have made full platform support for the Intel series of C++ compilers, including icl on windows and icc/icpc under linux/macOS.
To enable the Intel C++ compiler, we only need to switch to the corresponding toolchain through the --toolchain=icc
parameter on the system where the Intel compiler is installed.
$ xmake f --toolchain=icc
$ xmake
In the previous version, xmake only supported the gfortran compiler. In this version, we also support the Intel Fortran compiler, which is ifort. We only need to switch to the corresponding ifort tool chain to use it.
$ xmake f --toolchain=ifort
$ xmake
In the last version, we added the --toolchain=emcc
toolchain to support the compilation of wasm programs, but just specifying the toolchain does not adjust the extension of the target program well, for example, for *.js
and The file of *.wasm
is generated.
In the new version, we continue to add the xmake f -p wasm
platform, the built-in emcc tool chain is enabled, and the surrounding configuration has been improved again based on it.
As long as you switch to the wasm platform, xmake will generate *.js
and corresponding *.wasm
and other target files by default, and additionally generate *.html
pages that can load js to run the wasm program.
In addition, we also support Qt SDK for Wasm, for example, we create a Qt QuickApp project.
$ xmake create -t qt.quickapp_static quickapp
Here, we noticed that what we created is a Qt project that requires a static link. Because of the wasm version of the Qt library, we need to force a static link to the program to use it normally.
The content of the generated project file xmake.lua is roughly as follows:
add_rules("mode.debug", "mode.release")
includes("qt_add_static_plugins.lua")
target("demo")
add_rules("qt.quickapp_static")
add_headerfiles("src/*.h")
add_files("src/*.cpp")
add_files("src/qml.qrc")
add_frameworks("QtQuickControls2", "QtQuickTemplates2")
qt_add_static_plugins("QtQuick2Plugin", {linkdirs = "qml/QtQuick.2", links = "qtquick2plugin"})
qt_add_static_plugins("QtQuick2WindowPlugin", {linkdirs = "qml/QtQuick/Window.2", links = "windowplugin"})
qt_add_static_plugins("QtQuickControls2Plugin", {linkdirs = "qml/QtQuick/Controls.2", links = "qtquickcontrols2plugin"})
qt_add_static_plugins("QtQuickTemplates2Plugin", {linkdirs = "qml/QtQuick/Templates.2", links = "qtquicktemplates2plugin"})
In the above configuration, in addition to enabling the qt.quickapp_static
compilation rules, we also configure some necessary Qt plugins through qt_add_static_plugins
.
Next, we only need to switch to the wasm platform and make sure that the Qt SDK is set to complete the compilation.
$ xmake f -p wasm [--qt=~/Qt]
$ xmake
After the compilation is completed, xmake will generate demo.html and the corresponding demo.js/demo.wasm program in the build directory. We can open the demo.html page to run the Qt program we compiled. The display effect is as follows:
For a more detailed description of Qt/Wasm, see: Issue #956
xmake is a lightweight cross-platform build tool based on Lua. It uses xmake.lua to maintain project builds. Compared with makefile/CMakeLists.txt, the configuration syntax is more Concise and intuitive, very friendly to novices, can get started quickly in a short time, allowing users to focus more on the actual project development.
With the continuous iterative development of xmake in recent years, xmake has harvested 2.9K stars, 300+ forks, 30+ contributors on Github, and handled 900+ issues, 5400+ Commits, and active users are also growing.
Now, the xmake v2.3.7 version is released. In the new version, we mainly improved the stability and compatibility of xmake itself. Through two months of continuous iteration, we have fixed various user feedback problems, user experience and The stability has been greatly improved.
In addition, we also added support for TinyC and Emscripten (WebAssembly) compilation tool chains in this version.
Especially for the windows platform, we provide an additional xmake-tinyc installation package, which has a built-in tinyc compiler, so that users can completely escape the bloated vs environment, one-click installation, out of the box, only 5M installation package is needed Simple C programs can be developed, and a complete set of winapi header files are also included.
Finally, we also improved the trybuild mode compilation. Through xmake, third-party projects maintained by autotools/cmake can be quickly compiled, and cross-compilation environments such as android/ios/mingw can be quickly connected to achieve rapid migration and compilation.
In the new version, we submitted the xmake installation package to windows winget and ubuntu ppa repositories, we can install xmake more conveniently and quickly.
winget install xmake
sudo add-apt-repository ppa:xmake-io/xmake
sudo apt update
sudo apt install xmake
Of course, we also support many other installation methods. For detailed installation methods for other platforms, see: Installation Document.
Currently we have supported a lot of toolchain environments, and in this version, we have added support for TinyC and Emscripten (WebAssembly) compilation toolchains. We can quickly switch to the corresponding toolchain to compile with the following command.
xmake f --toolchain=[tinyc|emscripten]
xmake
In the new version, we also provide two additional installation packages, built-in and integrated TinyC compilation environment, the entire installation package only needs 5M, and also contains winsdk api.
The installation package can be found in the github/releases directory of xmake.
Through this installation package, we can completely get rid of the bloated vs development environment (several G) by compiling and developing C programs, realize one-click installation, and use it out of the box. It is very useful for us to brush leetcode and write some C test code. Yes, there is no need to install the entire vs for this particular installation.
In addition, if we want to view all toolchains supported by xmake, we can execute the following command, and the compilation configuration of xmake f -p cross --sdk=/xxx
can support more general cross toolchains.
$ xmake show -l toolchains
xcode Xcode IDE
vs VisualStudio IDE
yasm The Yasm Modular Assembler
clang A C language family frontend for LLVM
go Go Programming Language Compiler
dlang D Programming Language Compiler
gfortran GNU Fortran Programming Language Compiler
zig Zig Programming Language Compiler
sdcc Small Device C Compiler
cuda CUDA Toolkit
ndk Android NDK
rust Rust Programming Language Compiler
llvm A collection of modular and reusable compiler and toolchain technologies
cross Common cross compilation toolchain
nasm NASM Assembler
gcc GNU Compiler Collection
mingw Minimalist GNU for Windows
gnu-rm GNU Arm Embedded Toolchain
envs Environment variables toolchain
fasm Flat Assembler
tinyc Tiny C Compiler
emcc A toolchain for compiling to asm.js and WebAssembly
This version focuses on some improvements to the support of other languages, such as fortran compilation support, experimental support for zig language, and third-party dependency package support and cross-compilation support for golang/dlang.
Although, xmake focuses on c/c++ build support, other languages support xmake will also make some improvements from time to time. Its main purpose is not to replace their official build system, but only to support mixed compilation with c/c++ , To better serve c/c++ projects, After all, some c/c++ projects still occasionally call code interfaces of other languages, such as mixed calls with languages such as cuda, dlang, objc, swift, asm, etc., so xmake still provides some basic compilation support for them.
In addition, regarding c/c++, we also support the header file dependency format of the new /sourceDependencies xxx.json
output in the vs preview version (this is more reliable and stable for multi-language header file dependency detection).
Starting from this version, we have fully supported the use of the gfortran compiler to compile fortran projects, we can quickly create an empty project based on fortran by using the following command:
$ xmake create -l fortran -t console test
Its xmake.lua content is as follows:
add_rules("mode.debug", "mode.release")
target("test")
set_kind("binary")
add_files("src/*.f90")
More code examples can be viewed here: Fortran Examples
The main work of this version is to continue to improve the support of the tool chain. Although the previous version achieved modular tool chain extension through refactoring, for one compilation, I want to flexibly switch the compilation on the cross tool chain/Host tool chain. Not very good support, so this version focuses on improving the support of this piece.
In addition, this version also improves the problem of slow downloading of remote dependent packages integrated using add_requires
, adding proxy settings and local package retrieval multiplexing support to improve this problem. Of course, the best way is to get a domestic CDN to speed up the download, but this cost is too high, for the time being not toss.
There are some minor changes and bug fixes, you can see the updated content at the bottom of the article.
For an example of this, please refer to the luajit project. The compilation process needs to first compile the two targets minilua/buildvm under the host platform, and then generate the jit code corresponding to the target platform through minilua/buildvm to participate in the compilation of the overall luajit library.
Therefore, the entire compilation process needs to use the host tool chain for a specific target, and then use the cross tool chain to complete the compilation for other targets.
So how should we configure xmake.lua to achieve this way, one is to set the specified host toolchain for a specific target through the set_toolchains
interface, for example:
target("buildvm")
set_kind("binary")
add_files("src/*.c")
set_toolchains("xcode", {plat = os.host(), arch = os.arch()})
target("luajit")
set_kind("static")
add_deps("buildvm")
add_files("src/*.c")
If you are currently in cross-compilation mode, even if you execute the following command to configure the android compilation platform, its buildvm is still using xcode to compile the macOS target program, only the luajit library is compiled using the ndk toolchain:
$ xmake f -p android --ndk=/xxxx
However, this is not particularly convenient, especially when cross-platform compilation, pc tool chains of different platforms are different, there are msvc, xcode, clang, etc., you need to judge the platform to specify.
We can also continue to generalize and let xmake automatically select the currently available Host toolchain for different platforms, instead of explicitly specifying a specific toolchain, and improve it to the following version:
target("buildvm")
set_kind("binary")
add_files("src/*.c")
set_plat(os.host())
set_host(os.arch())
target("luajit")
set_kind("static")
add_deps("buildvm")
add_files("src/*.c")
By using set_plat and set_arch interface, directly set a specific target to the host platform, you can automatically select the host tool chain internally.
For a complete configuration example of this piece, you can refer to: https://github.com/xmake-io/xmake-repo/blob/master/packages/l/luajit/port/xmake.lua
In order to make xmake better support cross-compilation, this version I refactored the entire tool chain, making the tool chain switching more convenient and fast, and now users can easily extend their tool chain in xmake.lua.
With regard to platform support, we have added support for *BSD systems. In addition, this version also adds a ninja theme style to achieve ninja-like compilation progress display, for example: