xmake v2.6.4 released, a lot of package management features improved

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

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

It uses xmake.lua to maintain project construction. Compared with makefile/CMakeLists.txt, the configuration syntax is more concise and intuitive, and it is very friendly to novices. It can get started quickly in a short time, allowing users to focus more on actual project development. superior.

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

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

Xmake = Build backend + Project Generator + Package Manager

• project source code
• Official document
• Introductory course

Introduction of new features

More flexible package expansion

Now, we can inherit all the configuration of an existing package through the set_base interface, and then rewrite part of the configuration on this basis.

This is usually in the user's own project, it is more useful to modify the built-in package of the official repository of xmake-repo , such as: repairing and changing urls, modifying the version list, installation logic, etc.

For example, modify the url of the built-in zlib package and switch 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")

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

package("onetbb")
    set_base("tbb")

We can install the tbb package through add_requires("onetbb") integration, but the package name is different.

Package management supports toolchain switching

Previously, we limited the toolchains that can only be installed under the cross platform to switch packages. In the new version, we can support the switchover of toolchains under more platforms.

E.g:

$ xrepo install --toolchains=clang zlib

We can quickly switch to the clang toolchain to compile and install the zlib library on linux and other platforms.

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

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

The zlib packages installed by different toolchains will be stored in different directories without interfering with each other, and there will be no link compatibility problems caused by compiler differences.

Built-in package virtual environment

The Xrepo command has already well supported package virtual environment management, xrepo env shell , but for complex package environments, users still need to configure an xmake.lua file to manage their own package environments.

For example, we need a common development environment shell with common development tool chains such as cmake, python and vs/autoconf by default, and we need to create a configuration file devel.lua by ourselves.

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

Then, execute the following command to import into the global configuration.

$ xrepo env --add devel.lua

In this way, we can load the shell to bind this environment with the following command:

$ xrepo env -b devel shell
> cmake --version
cmake version 3.19.3

In the new version, we have built 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

Among them, devel is also in it, so we only need to execute xrepo env -b devel shell to bring up a devel development environment without configuring them ourselves.

Such as python, msvc, etc. are also some of the more commonly used environments, which can be used directly.

Of course, we also support temporarily creating an xmake.lua locally to configure the loading package environment instead of placing it in the global configuration.

Custom installation package download

We can customize the download logic of the package through the newly added on_download interface, which is usually not used. It is enough to use the built-in download of Xmake.

If the user builds a private repository and has a more complex authentication mechanism and special processing logic for the download of the package, the internal download logic can be rewritten to achieve this.

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

In the opt parameter, you can get the destination source directory opt.sourcedir of the download package. We only need to get the package address from package:urls() and download it.

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

ASN.1 program build support

ASN.1 programs need to use ASN.1 Compiler to generate relevant .c files to participate in project compilation.

And Xmake built-in provides add_rules("asn1c") rules to process .c file generation, add_requires("asn1c") automatically pulls the integrated ASN.1 compiler tool.

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")

For details, see complete example project .

Support all platforms to build Swift programs

Previously, Xmake only supported the construction of Swift programs under macOS with the help of the Xcode toolchain. In the new version, we have also made improvements to use the swift toolchain independently, and support the construction of swift programs on linux/windows. The usage is the same as before.

Support specified symbol list export

In previous versions, we provided utils.symbols.export_all for automatic full symbol export of dll libraries for windows.

Although this is very convenient, it can only support windows programs, and the full export is not easy to control the size of the generated dll, and there may be many internal symbols that are not needed at all to be exported.

However, the utils.symbols.export_list rule provided by our new version can directly define the list of exported symbols in xmake.lua, for example:

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

Alternatively, add the list of exported symbols in 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")

For a complete project example, see: 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, which is more general.

It automatically uses .def, version scripts and --exported_symbols_list to handle symbol exports.

Built-in support for linker scripts

In the new version, we also have built-in support for linker scripts and version scripts files, we can use add_files to add them directly without configuring add_ldflags("-Txxx.lds") .

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

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

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

We also support .ver , .map suffix files to be added as version script.

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

The content of the foo.map file is as follows:

{
    global:
        foo;

    local:
        *;
};

update content

new features

• #2011 : support inheritance and partial modification of official packages, such as replacing urls and versions for existing packages
• Supports compiling and running xmake on sparc, alpha, powerpc, s390x and sh4
• Add on_download custom download for package()
• #2021 : Support for building Swift programs under Linux/Windows
• #2024 : add asn1c support
• #2031 : add linker scripts and version scripts support for add_files
• #2033 : Capture ctrl-c to print the current running stack for debugging and analyzing stuck problems
• #2059 : add xmake update --integrate command to integrate shell
• #2070 : add some built-in xrepo env environment configuration
• #2117 : support passing toolchains to packages for any platform
• #2121 : support exporting the specified symbol list, which can be used to reduce the size of dynamic libraries

Improve

• #2036 : Improve xrepo to support batch installation of packages from configuration files, for example: xrepo install xxx.lua
• #2039 : Improve filter directory display of vs generator
• #2025 : support generating vs projects for phony and headeronly targets
• Optimize the detection speed of vs and codesign
• #2077 : improve vs project generator to support cuda

Bug fixes

• #2005 : fix path.extension
• #2008 : fix windows manifest file compilation
• #2016 : Fix compilation failure caused by object file name conflict in vs project generator