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, and it is very friendly to novices. You can get started quickly in a short time. Let users focus more on 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 have 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 use, 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 have 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.
Introduction of new features
More diverse installation methods
In the new version, we submitted the xmake installation package to the windows winget and ubuntu ppa repositories, and we can install xmake more conveniently and quickly.
Winget installation
winget install
Ubuntu PPA installation
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 of other platforms, see: Installation Documents .
Richer tool chain support
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
We are also in the new version, providing two additional installation packages, built-in and integrated TinyC compilation environment, the entire installation package only needs 5M, also contains winsdk api.
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 see all xmake tool chain support, you can execute the following command, another xmake f -p cross --sdk=/xxxcompilation configurations can support more generic cross-tool chain.
$ 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
TryBuild compilation mode improvements
The so-called trybuild mode is a feature introduced by xmake that adapts to existing third-party build systems, because most of the existing third-party projects are maintained by third-party build systems such as autotools/cmake. If they are migrated to xmake The cost of migration is still relatively high for configuration.
Although the configuration of xmake is very easy to get started, there is no need to change the build system for projects that have been stably maintained. xmake is mainly used to build and maintain some new projects.
Based on this background, xmake using trybuild compilation mode, which is called the attempt compilation mode, the system automatically detects third party by building the project, if it detects a maintenance autotools project, then automatically invoked ./configure; maketo compile.
If a project maintained by cmake is detected, cmake is automatically invoked to generate makefile/build.ninja to compile. For users who use xmake, it is always only necessary to execute the command xmake to complete the compilation, for example:
$ xmake
note: configure found, try building it or you can run `xmake f --trybuild=` to set buildsystem (pass -y or --confirm=y/n/d to skip confirm)?
please input: y (y/n)
y
...
CC src/pcre2grep-pcre2grep.o
CC src/libpcre2_8_la-pcre2_auto_possess.lo
CC src/libpcre2_8_la-pcre2_config.lo
...
build ok!
After xmake detected autotools build system will prompt the user whether to try to call autotools to compile, enter y to confirm, you can compile directly to cmake project is, only need to perform the same xmakecommand.
You don’t need to care about how autotools/cmake needs to be configured, used and compiled. After all, cmake needs to generate different build files for windows and linux platforms. The compilation methods are also different. One will call make and the other will call msbuild. Big.
Not only that, xmake also docked xmake -rdirectly to recompile, docking xmake cleanto achieve a unified file cleanup, docking xmake -vto achieve a unified view detailed compilation command.
TryBuild's cross-compilation support
If only compiles the current host platform, maybe you will say, what's this, cmake also cmake --build .be directly compiled, not how troublesome it.
So the question is, how to do cross-compilation? If you have used autotools/cmake to cross-compile and generate mingw/android/ios target programs, can cmake and autotools still handle it simply and consistently?
Autotools will not say much, anyway, I hate its cross-experience. Every time I cross-compile and transplant a code with an autotools project, it takes a long time. I often have to package various errors and study the transfer of various configuration parameters. Different platforms have different configurations.
And cmake I don’t think it’s easy to use, for example, for the Android platform, I have to do it like this:
$ cmake \
-DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake \
-DANDROID_ABI=$ABI \
-DANDROID_NATIVE_API_LEVEL=$MINSDKVERSION \
$OTHER_ARGS
For the ios platform, I did not find a short-answer configuration method, but found a third-party ios toolchain configuration, which is very complicated: https://github.com/leetal/ios-cmake/blob/master/ios.toolchain.cmake
For mingw, it is another way. I have been tossing about the environment for a long time, which is very tossing.
Then if you use xmake to dock cmake to achieve cross-compilation, you only need to do this.
Compile the android program:
xmake f -p android --trybuild=cmake --ndk=/xxx
xmake
Compile the ios program:
xmake f -p iphoneos --trybuild=cmake
xmake
Compile the mingw program:
xmake f -p mingw --trybuild=cmake --mingw=/sdk/xxx
xmake
We only need to configure through --trybuild=cmakeenabled cmake attempt compilation mode, and then -p android/iphoneos/mingwcut to the corresponding platform, docking the corresponding sdk, you can use the same way to quickly achieve a cross-compiler, even if this project is to use cmake to maintain.
If the user does not need to use cmake relation to transfer configure different tool chains, xmake are automatically handled for you, you simply need to execute xmake to compile, can also be performed xmake -rto re-compile, compile or check the details xmake -v.
In addition, you can also xmake f -p iphoneos -a arm64 --trybuild=cmakequickly switch compiler architecture.
Finally, we need to explain that although the trybuild mode can greatly help users save compilation and configuration operations, if the conditions are run, we still hope that everyone can directly use xmake.lua to maintain their own projects.
In this way, there is no need to compile by trybuild, and xmake will more perfectly support cross-compilation, because the internal xmake will directly compile the project without calling cmake, autotools and other tools, for example:
xmake f -p iphoneos
xmake
or
xmake f -p android --ndk=/xxx
xmake
You can see, this time we leave the --trybuild=cmakeargument, because no, we are directly translated, this time xmake equivalent separate make / ninja, and does not rely make, compilation speed can also be completely comparable ninja.
Improve the integration of remote dependency packages
Cross compilation support
xmake not only supports mingw/autotools cross-compilation support for trybuild, but also supports cross-compilation installation and integration for third parties maintained by cmake/autotools in remote package warehouses.
E.g:
add_requires("pcre2")
target("test")
set_kind("binary")
add_files("src/*.cpp")
add_packages("pcre2")
Then by switching to the iphoneos platform, you can quickly integrate and install the pcre2 package of the iphoneos platform, and then compile and link it, even if the pcre2 package is maintained by autotools/cmake.
xmake f -p iphoneos
xmake
Private network package warehouse
With this release, we rely on remote integration package also made some slight improvements, for example, can be configured xmake g --network=privatecut to the private network mode.
This is mainly used for some company's internal network through xmake's self-built package management warehouse to realize closed C/C++ dependency package integration, and will not rely on packages from the official warehouse provided by xmake at all.
Recursively export installed packages
Xmake previously provided a command to export all third-party dependency packages installed by xmake.
xmake require --export
However, the previous version corresponds to some packages that have dependencies. When exporting, only itself will be exported, and all its dependencies will not be exported. In this version, we have improved it and will also perform all corresponding dependent packages.了export.
Improve support for Qt SDK environment
In addition, this version also provides better support for the Qt SDK toolchain environment. For example, the Qt SDK toolchain installed through the apt command under the ubuntu system also supports the previous version, which can only be downloaded and installed from the Qt official website. The Qt SDK environment.
update content
New features
- #2941 : Support to install xmake through wingst
- Add xmake-tinyc installation package, built-in tinyc compiler, support windows without msvc environment can also directly compile c code
- Add tinyc compilation tool chain
- Add emcc (emscripten) compilation tool chain to compile asm.js and WebAssembly
- # 947 : The
xmake g --network=privateconfiguration settings private network mode, to avoid the remote dependencies access the Internet to download the compilation fails
Improve
- #907 : Improve the linker optimization options of msvc to generate a smaller executable program
- Improve Qt environment support under ubuntu
- #918 : Improve cuda11 toolchain support
- Improve Qt support, detect support for Qt sdk installed via ubuntu/apt, and optimize the detection efficiency
- Improve the CMake project file generator
- #931 : Improve export package, support exporting all dependent packages
- #930 : If the private package definition does not have a version definition, you can try to download the package directly
- #927 : Improve android ndk, support arm/thumb command mode switch
- Improve trybuild/cmake to support Android/Mingw/iPhoneOS/WatchOS tool chain