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.
Xmake is a lightweight and modern C/C++ project build tool based on Lua. Its 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 write some commonly used basic xmake.lua description configurations to achieve some simple C/C++ project build management. For most small projects, these configurations are completely sufficient. In the later advanced tutorials in this series, I will explain in detail how to use some advanced features to configure the project more flexibly and customized.
One line of description compiles all c source files in the src directory, and then generates an executable file named demo.
target("demo", {kind = "binary", files = "src/*.c"})
The above is a condensed version. Generally, we recommend the following expansion method:
target("demo")
set_kind("binary")
add_files("src/*.c")
The two are completely equivalent. If the configuration is short, it can be completely reduced to one line, and splitting into multiple lines is more convenient and flexible.
If there is no special purpose, we will use the second paragraph.
There are three main types of object files generated by common C/C++ projects: executable programs, static libraries, and dynamic libraries.
We can set it through set_kind() configuration, corresponding to: binary, static, shared
For example, if we want to compile the dynamic library, we just need to modify the kind:
target("demo")
set_kind("shared")
add_files("src/*.c")
The compilation macro settings are used by most c/c++ projects. Generally, if we set compilation flags to be passed to gcc/clang, we need to configure: -DXXX
In xmake, the add_defines() built-in interface is provided for configuration:
target("demo")
set_kind("shared")
add_files("src/*.c")
add_defines("XXX")
Xmake is a lightweight modern C/C++ project build tool based on Lua. Its main features are: easy to use syntax, more readable project maintenance, and a consistent build experience across platforms.
This article mainly explains in detail how to load and run the compiled target program, and how to debug.
xmake also provides a run command to directly run the generated executable file for quick and easy testing, for example:
$ xmake run
hello xmake!
We can also add environment variables to set the default running target program through the add_runenvs interface in xmake.lua.
Therefore, for PATH, it is very convenient to append values through this interface, and this interface supports multi-value setting, so it is usually used to set multi-value env with path sep. .
target("test")
set_kind("binary")
add_files("src/*.c")
add_runenvs("PATH", "/tmp/bin", "xxx/bin")
add_runenvs("LD_LIBRARY_PATH", "/tmp/lib", "xxx/lib")
For more description of this interface, you can see the documentation: add_runenvs interface documentation