xmake v2.6.3 release, support vcpkg list mode

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

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

It uses xmake Lua maintains project builds, compared to makefile / cmakelists Txt, the configuration syntax is more concise and intuitive, and is very friendly to novices. You can get started quickly in a short time, which allows users to focus more on the actual project development.

We can use it to directly compile projects like Make/Ninja, or generate project files like cmake / Mason. In addition, it has a built-in package management system to help users solve the problem of integrated use of C/C + + dependency libraries.

At present, Xmake is mainly used for the construction of C/C + + projects, but it also supports the construction of other native languages. It can realize mixed compilation with C/C + +. At the same time, the compilation speed is also very fast, which can be the same as Ninja.

Xmake = Build backend + Project Generator + Package Manager
  • Project source code
  • Official documents
  • introductory course

New version changes

This version mainly adds the following features:

  1. The version selection of vcpkg package is realized through the list mode of vcpkg
  2. python module building support
  3. Support in cmakelists Txt integrated Xrepo/Xmake package management

The rest are mainly scattered function improvements and bug fixes. You can see the update details at the end of the following. Some major changes will also be explained one by one below.

Introduction to new features

Support Vcpkg list mode

In the new version, Xmake adds vcpkg list mode support. Through it, 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"}}})

    add_packages("vcpkg::zlib", "vcpkg::fmt", "vcpkg::libpng")

However, there are still many restrictions on the version selection of vcpkg. You must specify the baseline by hard coding, and it does not support < = 1.0, 1.0 The semantic selection of versions such as X is much better than that of the previous version.

Dependency package management using Xrepo in CMake

We have added a separate project xrepo cmake.

It is a CMake wrapper of C/C + + package manager based on Xrepo/Xmake.

This allows you to use CMake to build your project while using Xrepo to manage dependent packages. Part of the inspiration for this project comes from CMake Conan.

Usage scenarios for this project:

  • An existing CMake project that wants to use the Xrepo management pack.
  • You must use CMake, but you want to use the new project package managed by Xrepo.

Use packages from official repositories

Official warehouse of Xrepo: xmake repo

xrepo.cmake provides xrepo_package function to manage packages.

    "foo 1.2.3"
    [CONFIGS feature1=true,feature2=false]
    [MODE debug|release]
    [OUTPUT verbose|diagnosis|quiet]

Some function parameters correspond directly to the Xrepo command options.

Call xrepo_ After package (foo), there are two ways to use foo package:

  • If you provide a cmake module to find it, call find_package(foo), refer to CMake `find_package ` documentation for more details
  • If the package does not provide a cmake module, foo_INCLUDE_DIR and foo_ LINK_ The dir variable will be set to include the package and library path. Use these variables to set the include and Library paths in cmake code.
  • If directory is specified_ Scope, then xrepo_package will run the following code (so that the user only needs to specify the library name in target_link_libraries)

This is an example cmakelists. Com using gflags package version 2.2.2 Txt is managed by Xrepo.

cmake_minimum_required(VERSION 3.13.0)


# Download xrepo.cmake if not exists in build directory.
if(NOT EXISTS "${CMAKE_BINARY_DIR}/xrepo.cmake")
    message(STATUS "Downloading xrepo.cmake from https://github.com/xmake-io/xrepo-cmake/")
    # mirror https://cdn.jsdelivr.net/gh/xmake-io/xrepo-cmake@main/xrepo.cmake
    file(DOWNLOAD "https://raw.githubusercontent.com/xmake-io/xrepo-cmake/main/xrepo.cmake"
                  TLS_VERIFY ON)

# Include xrepo.cmake so we can use xrepo_package function.

# Call `xrepo_package` function to use gflags 2.2.2 with specific configs.
xrepo_package("gflags 2.2.2" CONFIGS "shared=true,mt=true")

# `xrepo_package` sets `gflags_DIR` variable in parent scope because gflags
# provides cmake modules. So we can now call `find_package` to find gflags
# package.
find_package(gflags CONFIG COMPONENTS shared)

Use packages from a third repository

In addition to installing packages from officially maintained repositories, Xrepo can also install packages from third-party package managers, such as vcpkg/conan/conda/pacman/homebrew/apt/dub/cargo.

For the use of the command line, we can refer to the document: Xrepo command usage

We can also use it directly in cmake to install packages from third-party warehouses by simply adding the warehouse name as a namespace. For example: vcpkg::zlib, conan::pcre2

xrepo_package("conda::gflags 2.2.2")

Python module build support

We can use this rule to generate the python library module with pybind11, which will adjust the module name of the python library.

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


With soabi:

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

    add_rules("python.library", {soabi = true})

Add or delete header file list interface

Through this interface, you can add_ Delete the specified file from the header file list added by the headerfiles interface, for example:


In the above example, you can add test.exe from the src directory All header files except h, of course, can also be added_ Headerfiles ("src / *. H|test.h") to achieve the same goal, but this method is more flexible.

Add on_config configuration script

After xmake config is executed, this script will be executed before Build, which is usually used for configuration before compilation. It and on_ The difference is that on_load will be executed as long as the target is loaded, and the execution time is earlier.

If there are some configurations, it cannot be on_ If it is configured prematurely in load, it can be configured on_ Configure it in config.

In addition, its execution timing is better than before_build is still early. The general execution process is as follows:

on_load -> after_load -> on_config -> before_build -> on_build -> after_build

Built in Github proxy image configuration

Xmake provides some built-in image configurations that can be used directly, such as the image acceleration of github:

$ xmake g --proxy_pac=github_mirror.lua

We don't have to write PAC ourselves Lua, you can directly use it to speed up the download of github source.

Update content

New features

  • #1298: support vcpkg list mode installation package and realize the version selection of installation package
  • #1896: add python Library rules to build the pybind module and support soabi
  • #1939: add remove_files, remove_headerfiles and tag del_files as obsolete interface
  • Will on_ As a formal public interface, config is used for target and rule
  • Add riscv32/64 support
  • #1970: add CMake wrapper to support calling xrepo Integrated C/C + + package in CMakelists
  • Add the built-in GitHub image acceleration PAC proxy file, xmake g --proxy_pac=github_mirror.lua


  • #1923: improve the construction of linux driver and support the setting of custom linux headers path
  • #1962: improve armclang tool chain to support the construction of asm
  • #1959: improved vstudio project generator
  • #1969: add default option description

Bugs repair

  • #1875: fix the problem of failed deployment to generate Android Qt package
  • #1973: fix merge static library
  • #1982: fix the dependency construction of c++20 sub module under clang

Added by Albright on Fri, 25 Feb 2022 04:44:21 +0200