This version focuses on refactoring and optimization of the internal parallel build mechanism, enabling parallel compilation of source files between multiple targets, and support for parallel links. It also optimizes some internal losses of xmake and fixes some bugs that affect compilation speed. Through testing and comparison, the current overall build speed is basically the same as ninja. Compared to cmake/make, meson/ninja is much faster, because they have an extra step to generate makefile / build.ninja.
In addition, xmake also adds support for the sdcc compilation toolchain for compiling embedded programs such as 51/stm8.
For more optimization details, please see: issue #589
We did some comparison tests on termux and macOS. The test project is at: xmake-core
For a relatively large number of target projects, the new version of xmake improves its build speed even more.
| buildsystem | Termux (8core/-j12) | buildsystem | MacOS (8core/-j12) |
|---|---|---|---|
| xmake | 24.890s | xmake | 12.264s |
| ninja | 25.682s | ninja | 11.327s |
| cmake(gen+make) | 5.416s+28.473s | cmake(gen+make) | 1.203s+14.030s |
| cmake(gen+ninja) | 4.458s+24.842s | cmake(gen+ninja) | 0.988s+11.644s |
| buildsystem | Termux (-j1) | buildsystem | MacOS (-j1) |
|---|---|---|---|
| xmake | 1m57.707s | xmake | 39.937s |
| ninja | 1m52.845s | ninja | 38.995s |
| cmake(gen+make) | 5.416s+2m10.539s | cmake(gen+make) | 1.203s+41.737s |
| cmake(gen+ninja) | 4.458s+1m54.868s | cmake(gen+ninja) | 0.988s+38.022s |
There are not many changes in functions and features in this version. The main improvement is the scheduling module of the coroutine, which enables unified scheduling support for the three objects: process, socket, and pipe. We can operate processes in the coroutine at the same time. There are pipes.
This relies on the poller module provided by tbox, which uniformly encapsulates interfaces such as epoll/kqueue/select/poll/iocp to achieve cross-platform wait for socket/pipe object events. By providing consistent reactors, unified dispatching in coroutines is achieved. .
In addition, poller also adds support for waiting for process events. You can also wait for the exit event of the process at the same time through the same wait interface. Actually, there are still a lot of things about this.
E.g:
The relevant poller interfaces mainly include the following four, where object can be a process/pipe/socket object, and then set the corresponding event to wait at the same time.
tb_bool_t tb_poller_insert(tb_poller_ref_t poller, tb_poller_object_ref_t object, tb_size_t events, tb_cpointer_t priv);
tb_bool_t tb_poller_remove(tb_poller_ref_t poller, tb_poller_object_ref_t object);
tb_bool_t tb_poller_modify(tb_poller_ref_t poller, tb_poller_object_ref_t object, tb_size_t events, tb_cpointer_t priv);
tb_long_t tb_poller_wait(tb_poller_ref_t poller, tb_poller_event_func_t func, tb_long_t timeout);
In the past two months, I have made a lot of refactorings to improve xmake and added a lot of useful new features. Welcome to try it.
Some new features:
xmake project -k ninja project generation plugin to support generation of build.ninja build system filesSome improvements:
Some invisible improvements:
There are also some scattered bug fixes, see updates below.
xmake now supports the generation of ninja build files, allowing users to use ninja to quickly build projects maintained by xmake. I have to admit that in terms of build speed, ninja is indeed much faster than xmake. I will try to optimize the build speed of xmake in subsequent versions.
$ xmake project -k ninja
Then call ninja to build:
$ ninja
Or use the xmake command directly to call the ninja build, see below.
xmake v2.3.1 and above directly interface with other third-party build systems. Even if other projects do not use xmake.lua for maintenance, xmake can directly call other build tools to complete the compilation.
Then the user can directly use a third-party build tool to compile, so why use xmake to call it? The main benefits are:
xmake config, reuse the platform detection and SDK environment detection of xmake, simplify the platform configurationBuild systems currently supported:
For example, for a project maintained using cmake, executing xmake directly in the project root directory will automatically trigger a detection mechanism, detect CMakeLists.txt, and then prompt the user if cmake is needed to continue compiling.
$ xmake
note: CMakeLists.txt found, try building it (pass -y or --confirm=y/n/d to skip confirm)?
please input: y (y/n)
-- Symbol prefix:
-- Configuring done
-- Generating done
-- Build files have been written to:/Users/ruki/Downloads/libpng-1.6.35/build
[ 7%] Built target png-fix-itxt
[ 21%] Built target genfiles
[ 81%] Built target png
[ 83%] Built target png_static
...
output to/Users/ruki/Downloads/libpng-1.6.35/build/artifacts
build ok!
There are not many new features in this version. It mainly supports c++ 20 modules experimentally. Currently it supports the clang/msvc compiler. In addition, it improves a lot of user experience and improves some stability.
In addition, this version adds socket.io support and scheduling support for coroutine io to prepare for remote compilation of the next version and subsequent distributed compilation.
c++ modules have been officially included in the c++20 draft, and msvc and clang have been basically implemented on modules-ts Support, as c++20’s footsteps are getting closer and closer to us, xmake has also begun to support c++modules in advance.
At present xmake has fully supported the implementation of the modules-ts of msvc/clang. For gcc, since its cxx-modules branch is still under development, it has not officially entered the master. I have read the changelog inside, and the related flags are still in the process. Constantly changing, I feel that it has not stabilized, so I have not supported it yet.
For more information about xmake’s progress on c++modules: https://github.com/xmake-io/xmake/pull/569
I will not talk about the introduction of c++modules. This is mainly about how to build a c++modules project under xmake. Let’s look at a simple example:
target("hello")
set_kind("binary")
add_files("src/*.cpp", "src/*.mpp")
The above is a description of the xmake.lua that supports building c++modules files, where hello.mpp is the module file:
#include <cstdio>
export module hello;
using namespace std;
export namespace hello {
void say(const char* str) {
printf("%s\n", str);
}
}
Main.cpp is the main program that uses the hello module:
import hello;
int main() {
hello::say("hello module!");
return 0;
}
Next we execute xmake to build this program:
ruki:hello ruki$ xmake
[0%]: ccache compiling.release src/hello.mpp
[50%]: ccache compiling.release src/main.cpp
[100%]: linking.release hello
build ok!
xmake is a lightweight and modern c/c++ project building tool based on Lua. It’s main features are: easy to use syntax, easy to use project maintenance, and a consistent build experience across platforms.
This article mainly explains in detail how to compile libraries and executable programs that can run under android through xmake.
First of all, we need to prepare the ndk toolchain necessary for compiling the android native library. If you haven’t, you can download and decompress it from the official websit: Android NDK
If you want to get better backward compatibility, you can choose the r16 version, because this is the last version that supports armeabi. If there is no special requirement, you can download the latest version directly.
We only need to pass the decompressed ndk directory path to xmake to complete the configuration, and we can compile directly, for example:
$ xmake f -p android --ndk=~/downloads/android-ndk-r19c
$ xmake
Among them, -p android is used to switch to the android platform, because if you do not specify a platform, the target program of the current host platform will be compiled by default.
Generally, if there is no special requirement, the above configuration can complete the compilation of the android native program. Currently, xmake has built-in support for the generation of three types of target files: binary, static, and shared, which correspond to executable programs and .a static libraries. .so dynamic library.