Xmake is a lightweight cross-platform build tool based on Lua.

It is very lightweight and has no dependencies because it has the Lua runtime built in.

It uses xmake. Lua to maintain project builds. Compared to Makefile/cmakelists.txt, the configuration syntax is more concise and intuitive, very friendly to beginners, and can be quickly started in a short time, allowing users to focus more on the actual project development.

It can be used to compile projects directly like Make/Ninja, generate project files like CMake/Meson, and has a built-in package management system to help users integrate C/C++ dependencies.

Currently, Xmake is mainly used for C/C++ projects, but it also supports other native languages. It can be mixed with C/C++, and the compilation speed is very fast, on par with Ninja.

Xmake = Build backend + Project Generator + Package Manager
Copy the code
  • Program source code
  • The official documentation
  • An introductory course

New Features

More flexible package extensions

Now, we can inherit the entire configuration of an existing package through the set_base interface, and then override part of the configuration based on that.

This is often the case in a user’s own project, where it is useful to modify the built-in package of the official Xmake-repo repository, such as fixing urls, modifying the version list, installing logic, etc.

For example, modify the url of the built-in Zlib package to cut 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")
Copy the code

We can also use it to simply add an alias package.

package("onetbb")
    set_base("tbb")
Copy the code

We can integrate the TBB package installation through add_requires(“onetbb”), just with a different package name.

Package management supports toolchain switching

Previously, we limited the toolchain switch to cross platform. In the new version, we can switch toolchain switch to more platforms.

Such as:

$ xrepo install --toolchains=clang zlib
Copy the code

We can quickly switch to the Clang tool chain to compile and install zlib libraries on Linux and other platforms.

We can also switch them in the configuration file of xmake.lua.

add_requires("zlib", {configs = {toolchains = "gcc-11"}})
Copy the code

Zlib packages installed in different toolchains will be stored in different directories without interference, and there will be no link compatibility problems caused by compiler differences.

Built-in package virtual environment

The Xrepo command already supports package virtual environment management, Xrepo env shell, but for complex package environment, you still need to configure a xmake. Lua file to manage your own package environment.

For example, we need a common development environment shell with cmake, Python, vs/ Autoconf and other common development tool chains by default. We need to create our own configuration file devel.lua.

add_requires("cmake")
add_requires("python")
if is_host("linux"."bsd"."macosx") then
    add_requires("pkg-config"."autoconf"."automake"."libtool")
elseif is_host("windows") then
    set_toolchains("msvc")
end
Copy the code

Then, run the following command to import the global configuration.

$ xrepo env --add devel.lua
Copy the code

Thus, we can load the shell binding environment with the following command:

$xrepo env -b devel shell > cmake --version cmake version 3.19.3Copy the code

In the new version, we built in some commonly used environments, which can be viewed through xrepo env-l:

$ xrepo env -l
  - msvc
  - llvm-mingw
  - llvm
  - mingw-w64
  - devel
  - python3
  - depot_tools
  - python2
Copy the code

Devel is also in there, so we just need to execute xrepo env -b devel shell to bring up a Devel development environment without having to configure them ourselves.

Python, MSVC, etc are also some of the more common environments, can be used directly.

Of course, we also support temporarily creating a local xmake.lua to configure the package loading environment without placing it in the global configuration.

Download a customized installation package

The new on_download interface allows you to customize the package download logic, which is usually not used, and Xmake’s built-in download is sufficient.

If users build their own private repositories and have more complex authentication mechanisms for downloading packages, special processing logic, then you can rewrite the internal download logic to implement.

on_download(function (package, opt)
    -- download packages:urls() to opt.sourcedir
end)
Copy the code

In the opt parameter, the source directory for downloading the package is opt.sourcedir. All you need to do is get the package address from package:urls() and download it.

Then, as needed, add some custom processing logic. In addition, you can add your own download cache handling and so on.

Asn.1 program build support

Asn.1 program, need to use ASN.1 Compiler to generate relevant.c files to participate in project compilation.

While Xmake provides the add_rules(” ASn1c “) rule built-in to handle.c file generation, add_requires(” ASN1c “) automatically pulls integrated ASN.1 compiler tools.

Here is a basic configuration example:

add_rules("mode.debug"."mode.release")
add_requires("asn1c")

target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_files("src/*.asn1")
    add_rules("asn1c")
    add_packages("asn1c")
Copy the code

See the complete example project for details.

Support Swift application building across the platform

Previously, Xmake only supported building Swift programs on macOS with the help of Xcode toolchain. In the new version, we have also improved the ability to use Swift toolchain independently and support building Swift programs on Linux/Windows. The usage is the same as before.

Supports export of specified symbol list

In previous versions, we provided utils.symbols.export_all to implement automatic full symbol export from Windows DLL libraries.

While this is convenient, it only supports Windows programs, and full exports have little control over the size of the generated DLLS, potentially exporting many internal symbols that are not needed at all.

In the new version of the utils.symbols.export_list rule, we can directly define the exported symbol list in xmake. Lua, for example:

target("foo")
    set_kind("shared")
    add_files("src/foo.c")
    add_rules("utils.symbols.export_list", {symbols = {
        "add"."sub"}})
Copy the code

Alternatively, add a list of exported symbols to the *.export.txt file.

target("foo2")
    set_kind("shared")
    add_files("src/foo.c")
    add_files("src/foo.export.txt")
    add_rules("utils.symbols.export_list")
Copy the code

For a complete engineering example, see export symbol example

By specifying symbol export, we can make the generated dynamic library as small as possible, and do not export irrelevant internal symbols at all. In addition, this rule supports Linux, macOS and Windows, and is more general.

Internally, it automatically handles symbol exports using.def, version scripts, and –exported_symbols_list.

Built-in support for Linker Scripts

In the new version, we also have built-in support for Linker scripts and Version scripts files, which can be added directly using add_files without having to configure add_LDflags (” -txxx.lds “).

Currently.ld and.lds are supported to be added as linker scripts configuration files:

add_rules("mode.debug"."mode.release")

target("test")
    add_deps("foo")
    set_kind("binary")
    add_files("src/main.c")
    add_files("src/main.lds")
Copy the code

We also support.ver,.map files as version scripts.

target("foo")
    set_kind("shared")
    add_files("src/foo.c")
    add_files("src/foo.map")
Copy the code

The foo.map file contains the following contents:

{
    global:
        foo;

    local:
        *;
};
Copy the code

Update the content

New features

  • #2011: Support inheritance and partial modification of official packages, such as changing urls and versions of existing packages
  • Support to compile and run Xmake on Sparc, Alpha, PowerPC, S390x and SH4
  • Add the on_download custom download for Package ()
  • #2021: Support for building Swift applications on Linux/Windows
  • #2024: Add ASN1C support
  • #2031: Added support for Linker scripts and Version Scripts for add_files
  • #2033: Capture CtrL-C to print the current run stack for debugging and analysis of stuck issues
  • # 2059Add:xmake update --integrateCommand to integrate the shell
  • #2070: Add some built-in Xrepo ENV configuration
  • #2117: Support for passing toolchains to packages for any platform
  • #2121: Support for exporting specified symbol lists, which can be used to reduce the size of dynamic libraries

To improve the

  • # 2036: Improved Xrepo to support bulk installation of packages from configuration files, for example:xrepo install xxx.lua
  • #2039: Improved vs Generator filter directory presentation
  • #2025: Support generating VS projects for phony and Headeronly targets
  • Optimize detection speed for VS and CoDesign
  • #2077: Improved VS engineering generator to support CUDA

Bugs fix

  • # 2005: repair path. The extension
  • #2008: Fix Windows manifest file compilation
  • #2016: Fixed vs Project Generator compilation failure caused by object file name conflicts