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
In this version, we have added a lot of heavyweight new features:
With these features, we can compile large C/C++ projects faster.
In addition, they are completely cross-platform, support not only gcc/clang but also msvc, and there is no any third-party dependency except the compiler, which is very convenient to use.
Therefore, using Xmake is equivalent to using distcc/ccache/sccache at the same time.
Compared with these third-party tools, Xmake fully supports Windows and msvc, which eliminates platform differences, independent process calls, and the overhead of additional daemon processes.
In addition to these features, the new version of Xmake also adds support for compiling Keil/C51 projects, as well as support for the nvc/nvc++/nvfortran compilers in the nvidia-hpc-sdk toolchain.
In the last version, we initially supported remote compilation, but did not provide user authentication support, which would bring some security issues. Therefore, in this version, we added user authentication support.
At present, Xmake mainly provides the following authentication mechanisms. In addition, it is also effective for distributed compilation and remote caching.
This is also the default recommended method, which is more secure, more convenient to configure and connect, and does not need to enter a password every time you connect.
When we execute the xmake service command, a server and client configuration file will be generated by default,
and a default token will be automatically generated, so the local direct connection does not require any configuration.
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
The new version provides remote compilation support, which allows us to compile code on a remote server, run and debug remotely.
The server can be deployed on Linux/MacOS/Windows to enable cross-platform compilation, e.g. compile and run Windows programs on Linux and macOS/Linux programs on Windows.
It is more stable and smoother to use than ssh remote login compilation, no lagging of ssh terminal input due to network instability, and allows for quick local editing of code files.
We can even seamlessly implement remote compilation in editors and IDEs such as vs/sublime/vscode/idea without relying on the IDE’s own support for remote compilation.
$ xmake service
<remote_build_server>: listening 0.0.0.0:9096 ...
We can also turn on the service while displaying back detailed log messages.
$ xmake service -vD
<remote_build_server>: listening 0.0.0.0:9096 ...
$ xmake service --start
$ xmake service --restart
$ xmake service --stop
We start by running the xmake service command, which automatically generates a default service.conf configuration file, stored in ~/.xmake/service.conf.
Then, we edit it to fix the server’s listening port (optional).
{
logfile = "/Users/ruki/.xmake/service/logs.txt",
remote_build = {
server = {
listen = "0.0.0.0:9096"
}
}
}
We still edit this file ~/.xmake/service.conf to configure the address of the server to which the client needs to connect.
{
logfile = "/Users/ruki/.xmake/service/logs.txt",
remote_build = {
client = {
connect = "192.168.56.101:9096",
}
}
}
We can also import the given configuration file by using the following command.
$ xmake service --config=/tmp/service.conf
Next, we just need to go into the root directory of the project we need to compile remotely and execute the xmake service --connect command to make the connection.
$ xmake create test
$ cd test
$ xmake service --connect
<remote_build_client>: connect 192.168.56.110:9096 ...
<remote_build_client>: connected!
<remote_build_client>: sync files in 192.168.56.110:9096 ...
Scanning files ...
Comparing 3 files ...
[+]: src/main.cpp
[+]: .gitignore
[+]: xmake.lua
3 files has been changed!
Archiving files .
Uploading files with 1372 bytes ...
<remote_build_client>: sync files ok!
Once the connection is successful, we can build remotely as if we were building locally as normal.
```console $ xmake
Xmake is a lightweight cross-platform build tool based on Lua. We have done a detailed introduction to Xmake and build system in previous articles. Introduction: C/C++ build system, I use xmake.
If you already have a general understanding of Xmake, you will know that it is not only a build tool, but also has built-in support for C/C++ package management. We can also understand Xmake as:
Xmake = Build backend + Project Generator + Package Manager
After several years of continuous iteration, Xmake’s support for C/C++ package management has been continuously improved, and many useful package management features have been added. Therefore, in this article, we will make some summaries on it, hoping to help everyone.
The ecology of C++ is very complex, and there are certain historical reasons for this. In any case, the official does not provide native package management support. For our developers, it is somewhat inconvenient to use third-party C++ dependent libraries.
In fact, there are already many powerful C/C++ package managers, the most well-known and most used are: vcpkg, conan, conda, etc. Although they are very powerful, they have a common problem: The build system doesn’t have built-in support for them.
Since CMake does not provide built-in support for them, it is very cumbersome to use them in CMake to integrate dependencies, and the way of integration and use is inconsistent.
To use conan to integrate C/C++ packages in CMake, we need to provide additional CMake Wrapper scripts and inject them into our own projects in a similar way as plug-ins.
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
Now, we can inherit all the configuration of an existing package through the set_base interface, and then rewrite part of the configuration on this basis.
This is usually in the user’s own project, it is more useful to modify the built-in package of the official repository of xmake-repo, such as: repairing and changing urls, modifying the version list, Install logic and more.
For example, modify the url of the built-in zlib package to switch to your own zlib source address.
package("myzlib")
set_base("zlib")
set_urls("https://github.com/madler/zlib.git")
package_end()
add_requires("myzlib", {system = false, alias = "zlib"})
target("test")
set_kind("binary")
add_files("src/*.c")
add_packages("zlib")
We can also use it to simply add an alias package.
package("onetbb")
set_base("tbb")
We can install the tbb package through add_requires("onetbb") integration, but the package name is different.
Previously, we limited the toolchains that can only be installed under the cross platform to switch packages. In the new version, we can support the switchover of toolchains under more platforms.
E.g:
$ xrepo install --toolchains=clang zlib
We can quickly switch to the clang toolchain to compile and install the zlib library on platforms such as linux.
We can also switch them in the xmake.lua configuration file.
add_requires("zlib", {configs = {toolchains = "gcc-11"}})
The zlib packages installed by different tool chains will be stored in different directories without interfering with each other, and there will be no link compatibility problems caused by compiler differences.
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
This version mainly adds the following features:
The rest are mainly some scattered functional improvements and Bugs fixes. You can see the details of the update at the end of the following. Some major changes will be explained one by one below.
In the new version, Xmake adds vcpkg manifest mode support, through which we can support the version selection of vcpkg package, for example:
add_requires("vcpkg::zlib 1.2.11+10")
add_requires("vcpkg::fmt >=8.0.1", {configs = {baseline = "50fd3d9957195575849a49fa591e645f1d8e7156"}})
add_requires("vcpkg::libpng", {configs = {features = {"apng"}}})
target("test")
set_kind("binary")
add_files("src/*.cpp")
add_packages("vcpkg::zlib", "vcpkg::fmt", "vcpkg::libpng")
However, the version selection of vcpkg is still quite limited. It must be hard-coded to specify the baseline, and version semantic selection such as <=1.0, 1.x is not supported, but it is better than the previous version that cannot be selected.
CMake wrapper for Xrepo C and C++ package manager.
This allows using CMake to build your project, while using Xrepo to manage dependent packages. This project is partially inspired by cmake-conan.
Example use cases for this project:
Xrepo official repository: xmake-repo
xrepo.cmake provides xrepo_package function to manage packages.
xrepo_package(
"foo 1.2.3"
[CONFIGS feature1=true,feature2=false]
[MODE debug|release]
[OUTPUT verbose|diagnosis|quiet]
[DIRECTORY_SCOPE]
)