DEV Community: ruki

Xmake v2.7.3 Released, Package Components and C++ Modules Incremental Build Support

ruki — Wed, 09 Nov 2022 06:53:07 +0000

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

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

It uses xmake.lua to maintain project builds and its configuration syntax is very simple and readable.

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

Xmake = Build backend + Project Generator + Package Manager + [Remote|Distributed] Build + Cache

Although not very precise, we can still understand Xmake in the following way:

Xmake ~= Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache

Introduction of new features

Package component support

Introduction

This new feature is intended to enable the integration of specific sub-libraries from a C/C++ package, and is generally used for library component integration in larger packages.

This is because such packages provide a number of sub-libraries, not all of which are required by the user, and linking them all may be problematic.

Although, previous versions were able to support the feature of sublibrary selection, e.g.

add_requires("sfml~foo", {configs = {graphics = true, window = true}})
add_requires("sfml~bar", {configs = {network = true}})

target("foo")
    set_kind("binary")
    add_packages("sfml~foo")

target("bar")
    set_kind("binary")
    add_packages("sfml~bar")

This is done by custom configuration of each package, but there are some problems with this approach.

sfml~foo and sfml~bar will be installed repeatedly as two separate packages, taking up double the disk space
some common code will be compiled repeatedly, which will affect the efficiency of the installation
if a target depends on both sfml~foo and sfml~bar, there will be link conflicts

The impact of double-compilation and disk usage can be very high for very large package integrations such as boost, and can even lead to more than N times the disk usage if there are a large number of sub-library combinations.

To solve this problem, Xmake has added a package component mode, which offers some of the following benefits.

fast integration of any number of components in just one compile, greatly improving installation efficiency and reducing disk footprint
component abstraction, across compilers and platforms, so users don't need to worry about configuring link order dependencies between each sub library
easier to use

For more background details see: #2636

Use package components

For the user, using package components is very convenient because the user is not required to maintain the package, as long as the package is used, it is configured with the relevant set of components and we can quickly integrate and use it, e.g.

add_requires("sfml")

target("foo")
    set_kind("binary")
    add_packages("sfml", {components = "graphics"})

target("bar")
    set_kind("binary")
    add_packages("sfml", {components = "network"})

View package components

So how do we know what components are provided by a given package? We can check by executing the following command.

$ xrepo info sfml
The package info of project:
    require(sfml):
      -> description: Simple and Fast Multimedia Library
      -> version: 2.5.1
      ...
      -> components:
         -> system:
         -> graphics: system, window
         -> window: system
         -> audio: system
         -> network: system

Package component configuration

If you are a package maintainer and want to add component support to a package, then you need to configure the package components via the following two interfaces.

add_components: adds a list of package components
on_component: Configures each package component

Link configuration for package components

In most cases, a package component only needs to be configured with some of its own sub-link information, e.g.

package("sfml")
    add_components("graphics")
    add_components("audio", "network", "window")
    add_components("system")

    on_component("graphics", function (package, component)
        local e = package:config("shared") and "" or "-s"
        component:add("links", "sfml-graphics" ... e)
        if package:is_plat("windows", "mingw") and not package:config("shared") then
            component:add("links", "freetype")
            component:add("syslinks", "opengl32", "gdi32", "user32", "advapi32")
        end
    end)

    on_component("window", function (package, component)
        local e = package:config("shared") and "" or "-s"
        component:add("links", "sfml-window" ... e)
        if package:is_plat("windows", "mingw") and not package:config("shared") then
            component:add("syslinks", "opengl32", "gdi32", "user32", "advapi32")
        end
    end)

    ...

The above is an incomplete package configuration, I have only extracted a part of the configuration related to the package components.

A full example of the configuration and use of package components can be found at: components example

Configure compilation information for components

We can configure not only the linking information for each component, but also the compilation information for includedirs, defines etc. We can also configure each component individually.

package("sfml")
    on_component("graphics", function (package, component)
        package:add("defines", "TEST")
    end)

Configure component dependencies

package("sfml")
    add_components("graphics")
    add_components("audio", "network", "window")
    add_components("system")

    on_component("graphics", function (package, component)
          component:add("deps", "window", "system")
    end)

The above configuration tells the package that our graphics component will have additional dependencies on the window and system components.

So, on the user side, our use of the graphics component can be done from the

add_packages("sfml", {components = {"graphics", "window", "system"})

Simplified to

add_packages("sfml", {components = "graphics")

Because, as soon as we turn on the graphics component, it will also automatically enable the dependent window and system components and automatically ensure that the links are in the right order.

Alternatively, we can configure component dependencies with add_components("graphics", {deps = {"window", "system"}}).

Find components from the system library

We know that configuring add_extsources in the package configuration can improve package discovery on the system, for example by finding libraries from system package managers such as apt/pacman.

Of course, we can also make it possible for each component to prioritise finding them from the system repositories via the extsources configuration as well.

For example, the sfml package, which is actually also componentized in homebrew, can be made to find each component from the system repository without having to install them in source each time.

$ ls -l /usr/local/opt/sfml/lib/pkgconfig
-r--r--r-- 1 ruki admin 317 10 19 17:52 sfml-all.pc
-r--r--r-- 1 ruki admin 534 10 19 17:52 sfml-audio.pc
-r--r--r-- 1 ruki admin 609 10 19 17:52 sfml-graphics.pc
-r--r--r-- 1 ruki admin 327 10 19 17:52 sfml-network.pc
-r--r--r-- 1 ruki admin 302 10 19 17:52 sfml-system.pc
-r--r--r-- 1 ruki admin 562 10 19 17:52 sfml-window.pc

We just need, for each component, to configure its extsources: the

`lua
if is_plat("macosx") then
add_extsources("brew::sfml/sfml-all")
end

on_component("graphics", function (package, component)
-- ...
component:add("extsources", "brew::sfml/sfml-graphics")
end)
`

Default Global Component Configuration

In addition to configuring specific components by specifying component names, if we do not specify a component name, the default is to globally configure all components.

lua package("sfml") on_component(function (package, component) -- configure all components end)

Of course, we could also specify the configuration of the graphics component and the rest of the components would be configured via the default global configuration interface in the following way.

`lua
package("sfml")
add_components("graphics")
add_components("audio", "network", "window")
add_components("system")

on_component("graphics", function (package, component)
    -- configure graphics
end)

on_component(function (package, component)
    -- component audio, network, window, system
end)

C++ module build improvements

Incremental build support

I thought that Xmake already had good support for C++ modules, but then I realised that its incremental builds don't work properly yet.

So this version of Xmake also does a good job of supporting incremental builds of C++ modules, although the support process still took a lot of effort.

My analysis shows that the format of the include dependency information (*.d) generated with modules varies considerably between the compilers.

The gcc format is the most complex, but I got it to support it anyway.

build/.objs/dependence/linux/x86_64/release/src/foo.mpp.o: src/foo.mpp\ build/.objs/dependence/linux/x86_64/release/src/foo.mpp.o gcm.cache/foo.gcm: bar.c++m cat.c++m\ foo.c++m: gcm.cache/foo.gcm\ .PHONY: foo.c++m\ gcm.cache/foo.gcm:| build/.objs/dependence/linux/x86_64/release/src/foo.mpp.o\ CXX_IMPORTS += bar.c++m cat.c++m\

clang has the best format compatibility and supports it without any special changes.

build//hello.pcm: /usr/lib/llvm-15/lib/clang/15.0.2/include/module.modulemap src/hello.mpp\

The msvc format is more extensible and easier to parse and support: the

{ "Version": "1.2", "Data": { "Source": "c:\users\ruki\desktop\user_headerunit\src\main.cpp", "ProvidedModule": "", "Includes": [], "ImportedModules": [ { "Name": "hello", "BMI": "c:\users\ruki\desktop\user_headerunit\src\hello.ifc" } ], "ImportedHeaderUnits": [ { "Header": "c:\users\ruki\desktop\user_headerunit\src\header.hpp", "BMI": "c:\users\ruki\desktop\user_headerunit\src\header.hpp.ifc" } ] } }

Circular Dependency Detection Support

As there are dependencies between modules, it is not possible to compile if there are circular dependencies between several modules.

However, in previous versions Xmake was unable to detect this, and when a circular dependency was encountered, the compilation would get stuck without any message, which was very unfriendly to the user.

In this new version, we have improved this situation by adding the detection of cyclic dependencies for modules, and the following error message will appear when compiling to make it easier for the user to locate the problem.

bash $ xmake [ 0%]: generating.cxx.module.deps Foo.mpp [ 0%]: generating.cxx.module.deps Foo2.mpp [ 0%]: generating.cxx.module.deps Foo3.mpp [ 0%]: generating.cxx.module.deps main.cpp error: circular modules dependency(Foo2, Foo, Foo3, Foo2) detected! -> module(Foo2) in Foo2.mpp -> module(Foo) in Foo.mpp -> module(Foo3) in Foo3.mpp -> module(Foo2) in Foo2.mpp

A more LSP friendly syntax format

Our default convention of domain configuration syntax, although very clean, is not very friendly to auto-formatted indentation and IDEs, and if you format your configuration, the indentation is completely misplaced.

lua target("foo") set_kind("binary") add_files("src/*.cpp")

Also, if some global configuration is configured between two targets, it does not automatically end the current target scope and the user needs to explicitly call target_end()`.

target("foo")
    set_kind("binary")
    add_files("src/*.cpp")
target_end()

add_defines("ROOT")

target("bar")
    set_kind("binary")
    add_files("src/*.cpp")

Although, as we mentioned above, you can use the do end mode to solve the auto-indentation problem, the problem of needing target_end() still exists.

target("foo") do
    set_kind("binary")
    add_files("src/*.cpp")
end
target_end()

add_defines("ROOT")

target("bar") do
    set_kind("binary")
    add_files("src/*.cpp")
end

Therefore, in this new version, we provide a better optional domain configuration syntax to solve the auto-indentation, target domain isolation problem, e.g.

target("foo", function ()
    set_kind("binary")
    add_files("src/*.cpp")
end)

add_defines("ROOT")

target("bar", function ()
    set_kind("binary")
    add_files("src/*.cpp")
end)

The foo and bar fields are completely isolated, so we can configure other settings between them without affecting them, plus it's very LSP friendly and won't cause indentation confusion, even with one-click formatting.

Note: This is only an optional extension syntax, the existing configuration syntax is still fully supported and the user can choose the right one according to their needs preferences.

Add flags to specific compilers

Values configured using interfaces such as add_cflags, add_cxxflags, etc. are usually compiler specific, although Xmake does provide automatic detection and mapping mechanisms.
Even if a flags is set that is not supported by the current compiler, Xmake can automatically ignore it, but there will still be a warning.

In this new version, we have improved the interface for adding all flags to avoid additional warnings by specifying flags only for specific compilers, e.g.

add_cxxflags("clang::-stdlib=libc++")
add_cxxflags("gcc::-stdlib=libc++")

add_cxxflags("-stdlib=libc++", {tools = "clang"})
add_cxxflags("-stdlib=libc++", {tools = "gcc"})

Note: Not just compile flags, but also for link flags such as add_ldflags, which also work.

renderdoc debugger support

Thanks to @SirLynix for contributing this great feature which allows Xmake to load renderdoc directly to debug some graphics renderers.

It's very simple to use, we first make sure renderdoc is installed, then configure the debugger to renderdoc and load the debug run as follows

$ xmake f --debugger=renderdoc
$ xmake run -d

The concrete usage effect is as follows.

New C++ exception interface configuration

Xmake has added a new set_exceptions abstraction configuration interface, which allows us to configure C++/Objc exceptions to be enabled and disabled.

Normally, if we configure them via the add_cxxflags interface, it would be cumbersome for the compiler to handle them separately, depending on the platform.

For example

on_config(function (target)
    if (target:has_tool("cxx", "cl")) then
        target:add("cxflags", "/EHsc", {force = true})
        target:add("defines", "_HAS_EXCEPTIONS=1", {force = true})
    elseif(target:has_tool("cxx", "clang") or target:has_tool("cxx", "clang-cl")) then
        target:add("cxflags", "-fexceptions", {force = true})
        target:add("cxflags", "-fcxx-exceptions", {force = true})
    end
end)

And with this interface, we can abstract to configure them in a compiler-independent way.

Enabling C++ exceptions:

set_exceptions("cxx")

Disable C++ exceptions:

set_exceptions("no-cxx")

We can also configure to turn on objc exceptions at the same time.

set_exceptions("cxx", "objc")

or disable them.

set_exceptions("no-cxx", "no-objc")

Xmake automatically adapts the flags internally to the different compilers.

Support for ispc compilation rules

Xmake has added support for built-in rules for the ipsc compiler, thanks to @star-hengxing, which is used in the following way.

target("test")
    set_kind("binary")
    add_rules("utils.ispc", {header_extension = "_ispc.h"})
    set_values("ispc.flags", "--target=host")
    add_files("src/*.ispc")
    add_files("src/*.cpp")

Support for msvc's armasm compiler

Previous versions of Xmake added initial support for Windows ARM, but did not yet have good support for asm compilation, so in this version we have continued to improve Windows ARM support.

Support for msvc's armasm.exe and armasm64.exe is now available.

In addition, we have also improved package cross-compilation support for the Windows ARM platform.

New gnu-rm build rules

Xmake has also added a new rule and example project for building embedded projects using the gnu-rm toolchain, thanks to @JacobPeng for this.

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

add_requires("gnu-rm")
set_toolchains("@gnu-rm")
set_plat("cross")
set_arch("armv7")

target("foo")
    add_rules("gnu-rm.static")
    add_files("src/foo/*.c")

target("hello")
    add_deps("foo")
    add_rules("gnu-rm.binary")
    add_files("src/*.c", "src/*.S")
    add_files("src/*.ld")
    add_includedirs("src/lib/cmsis")

For the full project see: Embed GNU-RM Example

Add OpenBSD system support

In previous versions, Xmake only supported FreeBSD, and OpenBSD had a number of differences that prevented Xmake from compiling and installing on it.

The new version now fully supports running Xmake on OpenBSD.

Changelog

New features

A new optional configuration syntax. It is LSP friendly, automatically calls target_end() to achieve scope isolation.
#2944: Add gnu-rm.binary and gnu-rm.static rules and tests for embed project
#2636: Support package components
Support armasm/armasm64 for msvc
#3023: Add support for debugging with renderdoc
#3022: Add flags for specific compilers and linkers
#3025: C++ exception enabled/disabled switch method
#3017: Support ispc compiler

Changes

#2925: Improve doxygen plugin
#2948: Support OpenBSD
Add xmake g --insecure-ssl=y option to disable ssl certificate when downloading packages
#2971: Stabilize vs and vsxmake project generation
#3000: Incremental compilation support for modules
#3016: Improve clang/msvc to better support std modules

Bugs fixed

#2949: Fix vs group
#2952: Fix armlink for long args
#2954: Fix c++ module partitions path issue
#3033: Detect circular modules dependency

xmake v2.5.3 Released, Support to build Linux bpf program and integrate Conda packages

ruki — Thu, 08 Apr 2021 12:45:05 +0000

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, it is very friendly to novices, and you can get started quickly in a short time, allowing users to focus more on actual project development.

In version 2.5.3, we have been able to build linux and android bpf programs.

Although bpf has certain requirements for the compilation toolchain, such as the newer llvm/clang and android ndk toolchains, xmake can automatically pull a specific version of llvm/ndk for compilation, and it can also automatically pull libbpf dependencies. Library.

In addition, in the new version we have added support for the integration of C/C++ packages from Conda.

New feature introduction

Build a Linux Bpf program

In the new version, we started to support the compilation of bpf programs, as well as linux and android platforms, and can automatically pull the llvm and android ndk toolchains.

For more details, please see: #1274

The build configuration is as follows, it's very simple.

If we do not need to build the android version, we can remove some configuration about android.

add_rules("mode.release", "mode.debug")
add_rules("platform.linux.bpf")

add_requires("linux-tools", {configs = {bpftool = true}})
add_requires("libbpf")
if is_plat("android") then
    add_requires("ndk >=22.x")
    set_toolchains("@ndk", {sdkver = "23"})
else
    add_requires("llvm >=10.x")
    set_toolchains("@llvm")
    add_requires("linux-headers")
end

target("minimal")
    set_kind("binary")
    add_files("src/*.c")
    add_packages("linux-tools", "linux-headers", "libbpf")
    set_license("GPL-2.0")

Through the above configuration, we can probably see that we have integrated and configured specific versions of llvm and NDK toolchains,
as well as packages such as libbpf, linux-headers, linux-tools, etc..

xmake will automatically pull them, and then use the corresponding toolchain to integrate and compile these dependent packages, and finally generate the bpf program.

The linux-tools package mainly uses the libtool program inside to generate the bpf skeleton header file, and xmake will automatically run this tool to generate it.

Compile linux bpf program

We only need to execute the xmake command to complete the compilation, even if you have not installed llvm/clang.

Of course, if you have already installed them, if it's version is matched, xmake will also be used first.

$ xmake

We can also use xmake -v to compile and view the complete and detailed compilation commands:

$ xmake -v
[20%]: compiling.bpf src/minimal.bpf.c
/usr/bin/ccache /usr/bin/clang -c -Qunused-arguments -m64 -fvisibility=hidden -O3 -Ibuild/.gens/minimal/linux/x86_64/release/rules/bpf -isystem /home/ruki/ .xmake/packages/l/linux-tools/5.9.16/0c52e491268946fe9a4bc91d4906d66b/include -isystem /home/ruki/.xmake/packages/z/zlib/1.2.11/3a7e4427eda94fc69fad0009a1629fd8/include -isystem /home/ruki/.xmake /packages/l/libelf/0.8.13/ced4fdd8151a475dafc5f51e2a031997/include -isystem /home/ruki/.xmake/packages/l/libelf/0.8.13/ced4fdd8151a475dafc5f51e2a031997/include/libelf -isystem /home/ruki/.xmake /l/libcap/2.27/c55b28aa3b3745489b93895d0d606ed1/include -isystem /home/ruki/.xmake/packages/l/linux-headers/5.9.16/8e3a440cbe1f42249aef3d89f1528ecb/include -DNDEBUG -target bpf -g -o build/.gens/.gens /linux/x86_64/release/rules/bpf/minimal.bpf.o src/minimal.bpf.c
llvm-strip -g build/.gens/minimal/linux/x86_64/release/rules/bpf/minimal.bpf.o
bpftool gen skeleton build/.gens/minimal/linux/x86_64/release/rules/bpf/minimal.bpf.o
[40%]: ccache compiling.release src/minimal.c
/usr/bin/ccache /usr/bin/clang -c -Qunused-arguments -m64 -fvisibility=hidden -O3 -Ibuild/.gens/minimal/linux/x86_64/release/rules/bpf -isystem /home/ruki/ .xmake/packages/l/linux-tools/5.9.16/0c52e491268946fe9a4bc91d4906d66b/include -isystem /home/ruki/.xmake/packages/z/zlib/1.2.11/3a7e4427eda94fc69fad0009a1629fd8/include -isystem /home/ruki/.xmake /packages/l/libelf/0.8.13/ced4fdd8151a475dafc5f51e2a031997/include -isystem /home/ruki/.xmake/packages/l/libelf/0.8.13/ced4fdd8151a475dafc5f51e2a031997/include/libelf -isystem /home/ruki/.xmake /l/libcap/2.27/c55b28aa3b3745489b93895d0d606ed1/include -isystem /home/ruki/.xmake/packages/l/linux-headers/5.9.16/8e3a440cbe1f42249aef3d89f1528ecb/include -DNDEBUG -o build/.objs/minimal/linux/x86_64/ release/src/minimal.co src/minimal.c
[60%]: linking.release minimal
/usr/bin/clang++ -o build/linux/x86_64/release/minimal build/.objs/minimal/linux/x86_64/release/src/minimal.co -m64 -L/home/ruki/.xmake/packages/l /linux-tools/5.9.16/0c52e491268946fe9a4bc91d4906d66b/lib64 -L/home/ruki/.xmake/packages/z/zlib/1.2.11/3a7e4427eda94fc69fad0009a1629fd8/lib -L/home/ruki/.xmake/packages/l/libelf /0.8.13/ced4fdd8151a475dafc5f51e2a031997/lib -L/home/ruki/.xmake/packages/l/libcap/2.27/c55b28aa3b3745489b93895d0d606ed1/lib -s -lbpf -lz -lelf -lcap
[100%]: build ok!

Compile Android bpf program

If we compile the Android version, we only need to switch to the android platform, which is also very convenient

$ xmake f -p android
$ xmake

xmake will automatically download the ndk tool chain and the corresponding android version libbpf and other libraries to use.

$ xmake f -p android -c
checking for architecture ... armeabi-v7a
checking for Android SDK directory ... no
checking for NDK directory ... no
note: try installing these packages (pass -y to skip confirm)?
in local-repo:
  -> libcap 2.27 [linux, x86_64, from:linux-tools]
  -> libelf 0.8.13 [linux, x86_64, from:linux-tools]
  -> zlib 1.2.11 [linux, x86_64, from:linux-tools]
  -> linux-tools 5.9.16 [bpftool:y]
  -> ndk 22.0
  -> libelf#1 0.8.13 [toolchains:@ndk, from:libbpf]
  -> zlib#1 1.2.11 [toolchains:@ndk, from:libbpf]
  -> libbpf v0.3 [toolchains:@ndk]
please input: y (y/n)

  => install libcap 2.27 .. ok
  => install zlib 1.2.11 .. ok
  => install libelf 0.8.13 .. ok
  => install ndk 22.0 .. ok
  => install linux-tools 5.9.16 .. ok
  => install libelf#1 0.8.13 .. ok
  => install zlib#1 1.2.11 .. ok
  => install libbpf v0.3 .. ok
ruki@010689392c4d:/mnt/bpf_minimal$ xmake
[20%]: compiling.bpf src/minimal.bpf.c
[40%]: ccache compiling.release src/minimal.c
[60%]: linking.release minimal
[100%]: build ok!

Of course, if you have manually downloaded the corresponding version of the ndk toolchain, we can also specify it to use it instead of automatically pulling it.

$ xmake f -p android --ndk=/xxx/android-ndk-r22
$ xmake

However, if you download it yourself, remember to download at least the version above ndk r22, because clang in the lower version of ndk does not support the compilation and generation of bpf programs.

Finally, here is a complete bpf scaffolding project based on xmake, you can refer to: https://github.com/hack0z/libbpf-bootstrap

In addition, there is also a minimal bpf example program: https://github.com/xmake-io/xmake/tree/master/tests/projects/bpf/minimal

Integrate and use Conda package

Conda is a very powerful third-party package manager that supports binary package pull in various languages. Here we only use the C/C++ package inside.

Its integrated usage is similar to conan/vcpkg, except that the package namespace is changed to conda::

add_requires("conda::libpng 1.6.37", {alias = "libpng"})
add_requires("conda::openssl")
target("testco")
    set_kind("binary")
    add_files("src/*.cpp")
    add_packages("libpng", "conda::openssl")

Note: Although we support many third-party package managers, such as conan/conda/vcpkg/brew, etc., xmake also has its own package repository management.

There are currently nearly 300 commonly used packages that support different platforms, some of which are The package also supports android/ios/mingw and even cross-compilation environment.

Therefore, if the official xmake-repo repository already provides the required package, you can use it directly without specifying the package namespace.

Get host cpu information

In the current version, we have added a new core.base.cpu module and os.cpuinfo interface to obtain various information about the cpu, such as: cpu family/model, microarchitecture, core number, features and other information.

This is usually very useful in projects that pursue performance. These projects usually need to be optimized according to the CPU's memory model and extended instruction set. At the same time, if you want to cross-platform, you need to specify the corresponding code according to the current cpu information, (for example, after intel haswell) One set, one set after amd zen, the older ones default to no optimization). This information is also used in many high-performance computing libraries.

Therefore, through this module interface, you can obtain the current host cpu information and feature support when compiling and configuring, so as to enable relevant optimized compilation.

We can quickly obtain all information through os.cpuinfo(), or specify os.cpuinfo("march") to obtain specific information, such as march, which is microarchitecture

We can also use the xmake l command to quickly view the obtained results.

$ xmake l os.cpuinfo
{
  features = "fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clfsh ds acpi mmx fxsr sse sse2 ss htt tm pbe sse3 pclmulqdq dtes64 mon dscpl vmx tse64 mon dscpl vmx tse tm2 s
sse4_1 sse4_2 x2apic movbe popcnt aes pcid xsave osxsave seglim64 tsctmr avx1_0 rdrand f16c",
  vendor = "GenuineIntel",
  model_name = "Intel(R) Core(TM) i7-8569U CPU @ 2.80GHz",
  family = 6,
  march = "Kaby Lake",
  model = 142,
  ncpu = 8
}

$ xmake l os.cpuinfo march
"Kaby Lake"

$ xmake l os.cpuinfo ncpu
8

If you want to determine the support of extended features such as sse, you need to import the core.base.cpu module to get it.

target("test")
    set_kind("binary")
    add_files("src/*.c")
    on_load(function (target)
        import("core.base.cpu")
        local ncpu = os.cpuinfo("ncpu")
        - local ncpu = cpu.number()
        if cpu.has_feature("sse") then
            target:add("defines", "HAS_SSE")
        end
    end)

Added cmake import file rules

If we are developing a library program, after executing xmake install to install to the system, only the library file is installed, and there is no import file information such as .cmake/.pc, so the cmake project wants to be integrated and used through find_package, usually by looking for Not in our library.

In order to allow the third-party cmake project to find it normally and use the integration, then we can use the utils.install.cmake_importfiles rule to export the .cmake file when installing the target target library file for the library import and search of other cmake projects .

We only need to apply this rule to the specified target library target through the add_rules interface.

target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_rules("utils.install.cmake_importfiles")

After configuration, the xmake install installation command can automatically export the .cmake import file.

Added pkgconfig import file rules

Similar to the cmake_importfiles above, but we can also install the pkgconfig/.pc import file through the utils.install.pkgconfig_importfiles rule, which is very useful for library detection by tools such as autotools.

target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_rules("utils.install.pkgconfig_importfiles")

Added Git related built-in configuration variables

xmake has always provided the automatic generation feature of config.h, which can be configured through the add_configfiles interface, and it also supports the replacement of template variables. You can define some variables yourself.

However, xmake also provides some commonly used built-in variable substitutions, such as version information, platform architecture, etc. For details, see: https://xmake.io/#/manual/project_target?id=targetadd_configfiles

The template configuration is very simple, just need:

target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_configfiles("src/config.h.in")

The config.h file can be automatically generated according to config.h.in.

But the new feature we are going to talk about here is the newly provided Git-related built-in variables to allow users to quickly and conveniently compile the project or the latest tag/branch/commit information of the current git project.

This is very useful for troubleshooting and locating problems in the later stage.

We can use commit to pinpoint the problem library based on which commit submission caused the problem. In this way, we can checkout but the corresponding version to troubleshoot the problem.

We only need to configure and define the following variables in config.h.in.

#define GIT_COMMIT "${GIT_COMMIT}"
#define GIT_COMMIT_LONG "${GIT_COMMIT_LONG}"
#define GIT_COMMIT_DATE "${GIT_COMMIT_DATE}"
#define GIT_BRANCH "${GIT_BRANCH}"
#define GIT_TAG "${GIT_TAG}"
#define GIT_TAG_LONG "${GIT_TAG_LONG}"
#define GIT_CUSTOM "${GIT_TAG}-${GIT_COMMIT}"

Execute xmake to compile, it will automatically generate the following config.h file.

#define GIT_COMMIT "8c42b2c2"
#define GIT_COMMIT_LONG "8c42b2c251793861eb85ffdf7e7c2307b129c7ae"
#define GIT_COMMIT_DATE "20210121225744"
#define GIT_BRANCH "dev"
#define GIT_TAG "v1.6.6"
#define GIT_TAG_LONG "v1.6.6-0-g8c42b2c2"
#define GIT_CUSTOM "v1.6.6-8c42b2c2"

We can use them in the program by means of macro definitions.

Android NDK r22 support and remote pull

The Android NDK has made very big structural changes since r22, removing some obsolete directories, such as the top-level sysroot directory and platforms directory,
causing the previous detection method of xmake to fail.

Therefore, in the new version, we have made improvements to xmake to better support the full version of the NDK toolchain, including the new version above r22.

At the same time, the official repository of xmae-repo has also added the inclusion of ndk packages, enabling xmake to pull the ndk tool chain remotely for use.

add_requires("ndk >=22.x")
set_toolchains("@ndk", {sdkver = "23"})
target("test")
    set_kind("binary")
    add_files("src/*.c")

Changelog

New features

#1259: Support add_files("*.def") to export symbols for windows/dll
#1267: add find_package("nvtx")
#1274: add platform.linux.bpf rule to build linux/bpf program
#1280: Support fetchonly package to improve find_package
Support to fetch remote ndk toolchain package
#1268: Add utils.install.pkgconfig_importfiles rule to install *.pc import file
#1268: Add utils.install.cmake_importfiles rule to install *.cmake import files
#348: Add platform.longpaths policy to support git longpaths
#1314: Support to install and use conda packages
#1120: Add core.base.cpu module and improve os.cpuinfo()
#1325: Add builtin git variables for add_configfiles

Change

#1275: Support conditionnal targets for vsxmake plugin
#1290: Improve android ndk to support >= r22
#1311: Add packages lib folder to PATH for vsxmake project

Bugs fixed

#1266: Fix relative repo path in add_repositories
#1288: Fix vsxmake generator with option configs

xmake v2.5.2 released, Support pull remote cross toolchain and package integration

ruki — Mon, 01 Mar 2021 00:03:59 +0000

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, it is very friendly to novices, and you can get started quickly in a short time, allowing users to focus more on actual project development.

In version 2.5.2, we added a heavyweight new feature: Pull remote cross-compilation toolchain automatically.

Those who have done cross-compilation and have experience in C/C++ project migration should know that it is very troublesome to toss various cross-compilation toolchains
and transplant and compile projects. You need to download the corresponding toolchain yourself.

And it is easy to make mistakes in configuring the toolchain and the compilation environment to cause compilation failure.

Now, xmake can already support the automatic download of the toolchain required by the project, and then use the corresponding toolchain to directly compile the project.
The user does not need to care about how to configure the toolchain. In any case, just execute the xmake command to complete the compilation.

Even for the integration of C/C++ dependent packages, you can automatically switch to the corresponding toolchain to compile, install, and integrate.
Everything is fully automated and does not require users to worry about it.

In addition to the cross-compilation toolchain, we can also automatically pull toolchains, such as specific versions of llvm, llvm-mingw, zig
and other toolchains to participate in the compilation of C/C++/Zig projects.

Even cmake does not support the automatic pull of the toolchain. At most, it can only cooperate with third-party package management such as vcpkg/conan to integrate C/C++ dependent packages.
In addition, even for C/C++ dependent packages, xmake has its own native The built-in package management tool has no dependencies at all.

New feature introduction

Automatically pull the remote cross-compilation toolchain

Starting from version 2.5.2, we can pull the specified toolchain to integrate the compilation project, and we also support switching the dependent package to the corresponding remote toolchain to participate in the compilation and integration.

For related example codes, see: Toolchain/Packages Examples

Related issue #1217

Currently, we have included the following toolchain packages in the xmake-repo repository, allowing xmake to pull and integrate remotely:

llvm
llvm-mingw
gnu-rm
muslcc
zig

Although there are not many toolchain packages currently supported, but the overall architecture has been opened up, we only need to include more toolchains in the later stage, such as: gcc, tinyc, vs-buildtools and other toolchains.

Since the xmake package supports semantic versions, if the project relies on a specific version of the gcc/clang compiler, users should not bother to install it. xmake will automatically detect whether the gcc/clang version of the current system meets the requirements.

If the version is not satisfied, xmake will pull it remotely, automatically install and integrate a specific version of gcc/clang, and then compile the project.

Pull the specified version of llvm toolchain

We use clang in llvm-10 to compile the project.

add_requires("llvm 10.x", {alias = "llvm-10"})
target("test")
    set_kind("binary")
    add_files("src/*.c)
    set_toolchains("llvm@llvm-10")

Among them, the first half of llvm@llvm-10 is the toolchain name, which is toolchain("llvm"), and the following name is the name of the toolchain package that needs to be associated, which is package("llvm") , But if an alias is set, the alias will be used first: llvm-10

In addition, we will add the gcc toolchain package to xmake-repo in the future, so that users can freely switch to gcc-10, gcc-11 and other specific versions of gcc compilers without the need for users to manually install them.

Pull the cross-compilation toolchain

We can also pull the specified cross-compilation toolchain to compile the project.

add_requires("muslcc")
target("test")
    set_kind("binary")
    add_files("src/*.c)
    set_toolchains("@muslcc")

muslcc is a cross-compilation toolchain provided by https://musl.cc. By default, xmake will automatically integrate and compile the x86_64-linux-musl- target platform.

Of course, we can also use xmake f -a arm64 to switch to the aarch64-linux-musl- target platform for cross-compilation.

Pull the toolchain and integrate the dependency packages

We can also use the specified muslcc cross-compilation toolchain to c

xmake v2.5.1 released, Support for Apple Silicon and more powerful package management

ruki — Thu, 21 Jan 2021 10:26:05 +0000

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, very friendly to novices, can get started quickly in a short time, allowing users to focus more on the actual project development.

This is the first version of xmake this year and the first version that is fully adapted to support Apple Silicon (macOS ARM) devices.

In this version, we mainly improved the integrated support for C/C++ dependent packages, which is more stable, and can be more flexible to achieve customized configuration compilation.

In addition, we also focused on improving the vs/vsxmake two vs project generator plugins, fixing many details, and also supporting the sub-project group, and now it is possible to generate a project structure similar to the following figure.

About Zig, because it has fixed a lot of problems that I have reported before in v0.7.1. Now xmake can already support the compilation of zig projects.

At the same time, we have newly developed a luarocks-build-xmake plugin to replace luarocks' built-in build system with xmake.

Finally, in this version, we continue to improve the xmake f --menu graphical configuration menu, which fully supports mouse operation and scrolling support, and also supports utf8.

New feature introduction

Add add_requireconfs to improve package configuration

Despite the previous version, we can define and configure dependent packages by add_requires("libpng", {configs = {shared = true}}).

However, if the user project has a huge project and many dependent packages, and each package requires different compilation configuration parameters, the configuration will still be very cumbersome and has limitations, such as the inability to rewrite the internal sub-dependent package configuration.

Therefore, we have added add_requireconfs to configure the configuration of each package and its sub-dependencies more flexibly and conveniently. Below we focus on several usages:

Set the configuration of the specified package

This is the basic usage. For example, we have declared a package through add_requires("zlib"), and want to expand the configuration of this zlib later and change it to dynamic library compilation. You can configure it in the following way.

add_requires("zlib")
add_requireconfs("zlib", {configs = {shared = true}})

It is equivalent to

add_requires("zlib", {configs = {shared = true}})

Set general default configuration

The above usage, we still don't see any practical use, but if we rely on more we can see the effect, such as the following:

add_requires("zlib", {configs = {shared = true}})
add_requires("pcre", {configs = {shared = true}})
add_requires("libpng", {configs = {shared = true}})
add_requires("libwebp", {configs = {shared = true}})
add_requires("libcurl", {configs = {shared = false}})

Is it very cumbersome, if we use add_requireconfs to set the default configuration, it can be greatly simplified to the following configuration:

add_requireconfs("*", {configs = {shared = true}})
add_requires("zlib")
add_requires("pcre")
add_requires("libpng")
add_requires("libwebp")
add_requires("libcurl", {configs = {shared = false}})

For the above configuration, we use pattern matching through add_requireconfs("*", {configs = {shared = true}}) to set all dependent packages to compile and install dynamic libraries by default.

However, we used add_requires("libcurl", {configs = {shared = false}}) to configure libcurl to compile and install static libraries.

The final configuration result is: zlib/pcre/libpng/libwebp is a shared library, and libcurl is a static library.

Through pattern matching, we can put some common configurations of each package into the unified add_requireconfs to pre-configure, which greatly simplifies the definition of each add_requires.

!> By default, for the same configuration, xmake will give priority to the configuration in add_requires instead of add_requireconfs.

If the version is set in add_requires("zlib 1.2.11"), the configuration of add_requires will be used first, and the version configuration in add_requireconfs will be completely ignored. Of course, we can also completely override the version specified in add_requires through override .

add_requires("zlib 1.2.11")
add_requireconfs("zlib", {override = true, version = "1.2.10"})

Rewrite package dependency configuration

In fact, the biggest use of add_requireconfs is to allow users to rewrite the configuration of specific dependent packages of the installation package.

What does it mean? For example, our project integrates the package libpng and uses a dynamic library version, but the zlib library that libpng depends on is actually a static library version.

add_requires("libpng", {configs = {shared = true}})

So if we want to change the zlib package that libpng depends on to be compiled as a dynamic library, how should we configure it? This requires add_requireconfs.

add_requires("libpng", {configs = {shared = true}})
add_requireconfs("libpng.zlib", {configs = {shared = true}})

Through the writing method of libpng.zlib dependency path, specify an internal dependency and rewrite the internal dependency configuration.

If the dependency path is deep, such as the dependency chain of foo -> bar -> xyz, we can write: foo.bar.xyz

We can also rewrite the internal zlib library version that libpng depends on:

add_requires("libpng")
add_requireconfs("libpng.zlib", {version = "1.2.10"})

Pattern matching for cascading dependencies

If a package has a lot of dependencies, and the dependency level is also very deep, what to do, for example, the package libwebp, its dependencies are:

libwebp
  - libpng
    - zlib
    - cmake
  - libjpeg
  - libtiff
    - zlib
  - giflib
  - cmake

If I want to rewrite all the dependent libraries in libwebp to add specific configuration, then the configuration one by one will be very cumbersome. At this time, the recursive dependency pattern matching of add_requireconfs() is needed to support.

add_requires("libwebp")
add_requireconfs("libwebp.**|cmake", {configs = {cxflags = "-DTEST"}})

In the above configuration, we added -DTEST to compile all the library dependencies in libwebp, but the cmake dependency is a build tool dependency, and we can exclude it by way of |xxx.

The pattern matching here is very similar to add_files().

We are giving a few examples. For example, this time we only rewrite the single-level dependency configuration under libwebp to enable the debugging library:

add_requires("libwebp")
add_requireconfs("libwebp.*|cmake", {debug = true})

Graphical configuration supports mouse and scroll operations

We upgraded the tui component library used by xmake: LTUI, added support for the mouse, and scrolling support for some components, we can go to the graphical configuration, More flexible and convenient configuration of compilation options.

stdin redirect support

In the previous version, the process execution interface such as os.execv/os.runv provided by xmake only supports stdout/stderr output redirection, but does not support stdin input redirection, so in this version, we also do it Supported.

The usage is as follows:

os.execv("foo", {"arg1", "arg2"}, {stdin = "/tmp/a"})

When we execute the process, we can use the /tmp/a file as the redirected input. Of course, we can also pass {stdout = "/tmp/out"} as the redirected output.

vs project grouping support

We have added a new interface set_group to support grouping of each target. This interface is currently only used for vs/vsxmake project generation. The subproject directory tree within the vs project is displayed in groups according to the specified structure, but it may also be Other modules increase grouping support.

For example, for the following grouping configuration:

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

target("test1")
    set_kind("binary")
    add_files("src/*.cpp")
    set_group("group1")

target("test2")
    set_kind("binary")
    add_files("src/*.cpp")
    set_group("group1")

target("test3")
    set_kind("binary")
    add_files("src/*.cpp")
    set_group("group1/group2")

target("test4")
    set_kind("binary")
    add_files("src/*.cpp")
    set_group("group3/group4")

target("test5")
    set_kind("binary")
    add_files("src/*.cpp")

target("test6")
    set_kind("binary")
    add_files("src/*.cpp")

The effect of the generated VS project directory structure is as follows:

Among them, set_group("group1/group2") can set the target to the secondary group.

Automatically update vs project

If you feel that it is cumbersome to generate and update the VS project through the xmake project -k vsxmake command every time, we can now configure the plugin.vsxmake.autoupdate rule in xmake.lua to achieve automatic update.

Users can automatically update the VS project if there are changes to the file list or xmake.lua after each execution of the build in the VS project.

add_rules("plugin.vsxmake.autoupdate")

target("test")
    set_kind("binary")
    add_files("src/*.c")

Improve vs/vsxmake project plugin

In addition to the group support and automatic updates mentioned above, in this version, we also fixed a lot of VS project-related issues, such as: intellisense prompt improvement, path truncation problem repair, full support for remote dependency packages

Improve windows registry support

xmake improves the internal winos module and adds some interfaces to access the registry more conveniently and obtain the registry configuration on windows.

winos.registry_keys

Get the list of registry builds

Support through pattern matching, traverse to obtain the registry key path list, * is single-level path matching, ** is recursive path matching.

local keypaths = winos.registry_keys("HKEY_LOCAL_MACHINE\\SOFTWARE\\*\\Windows NT\\*\\CurrentVersion\\AeDebug")
for _, keypath in ipairs(keypaths) do
    print(winos.registry_query(keypath .. ";Debugger"))
end

winos.registry_values

Get a list of registry value names

Support to obtain the value name list of the specified key path through pattern matching, and the string after the ; is the specified key name pattern matching string.

local valuepaths = winos.registry_values("HKEY_LOCAL_MACHINE\\SOFTWARE\\xx\\AeDebug;Debug*")
for _, valuepath in ipairs(valuepaths) do
    print(winos.registry_query(valuepath))
end

winos.registry_query

Get the registry value

Get the value under the specified registry path, if the value name is not specified, then get the default value of the key path

local value, errors = winos.registry_query("HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug")
local value, errors = winos.registry_query("HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug;Debugger")

Support for building Zig project

In the last version, xmake has experimentally supported zig, but there were also many pitfalls during the period, especially when building on windows/macos encountered many problems.

Then in the latest zig 0.7.1, most of the problems I encountered have been fixed, and now xmake can already support zig project compilation.

We can quickly create a Zig empty project with the following command:

$ xmake create -l zig console

The content of xmake.lua is as follows:

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

target("console")
    set_kind("binary")
    add_files("src/*.zig")

As you can see, the configuration method is actually no different from C/C++. Because Zig and C have good binary compatibility, we can also use add_requires to add remote dependency support for C/C++ packages to the zig project.

Then execute xmake to complete the compilation.

$ xmake

Then continue to run the run command, you can directly execute the zig program and output the running result.

$ xmake run
Hello world!

We can also easily implement the mixed compilation support of C and Zig, just add the corresponding C code file.

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

target("console")
    set_kind("binary")
    add_files("src/*.zig", "src/*.c")

For complete code examples, see: Zig with C

Luarocks plugin

luarocks is a package management tool of lua, which provides the installation and integration of various lua modules, but it uses a built-in construction mechanism to build lua c modules.

For example, in its rockspec file, the builtin build type is used to describe the construction of common lua c modules:

build = {
    type = "builtin",
    modules = {
        ["module.hello"] = {
            sources = "src/test.c"
        }
    },
    copy_directories = {}
}

This is not a problem for small modules, but if the c code structure of the module is more complicated, its built-in construction rules still have many limitations and are not flexible. In addition, switching msvc / mingw tool chain and parameter configuration etc. Neither is flexible enough.

Therefore, xmake provides luarocks=build-xmake plugin to use xmake to replace the built-in build system of luarocks. The replacement method is also very simple. You only need to buildin Change the build type to xmake and add the luarocks-build-xmake dependency.

dependencies = {
    "lua >= 5.1",
    "luarocks-build-xmake"
}
build = {
    type = "xmake",
    modules = {
        ["module.hello"] = {
            sources = "src/test.c"
        }
    },
    copy_directories = {}
}

But this is still very cumbersome. It is still necessary to describe the rules based on the source file list in the modules in the rockspec file, and then luarocks-build-xmake will automatically generate xmake.lua according to the configuration to complete the build.

But since xmake is used, your own lua module can be maintained with xmake.lua, so the build configuration is more flexible, so we only need the following.

dependencies = {
    "lua >= 5.1",
    "luarocks-build-xmake"
}
build = {
    type = "xmake",
    copy_directories = {}
}

You only need to set the current switch to xmake compilation, and use the xmake.lua rules file built into the lua module project.

Support for deploying Qt programs on windows

Thank you very much for the contribution of @SirLynix, xmake can already support the deployment and installation of Qt applications on windows.

We only need to maintain a Qt program normally, for example:

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

target("demo")
     add_rules("qt.quickapp")
     add_headerfiles("src/*.h")
     add_files("src/*.cpp")
     add_files("src/qml.qrc")

Then, we only need to execute the following compile and install commands, and xmake will automatically call the windeployqt.exe program to install and deploy our Qt application.

$ xmake
$ xmake install -o d:\installdir

Related patches: #1145

In addition, in the previous version, xmake has also supported the deployment and packaging of Qt programs for macOS and android versions. Each time only normal compilation commands are required, the QT .app/.apk installation package can be generated.

$ xmake f -p android --ndk=/xxx/android-ndk-r20b --sdk=/xxx
$ xmake

Some bug fixes

We have also fixed many problems reported by users. Here we introduce some more important bug fixes, such as:

We fixed the problem of empty double quotes in add_defines("TEST=\"hello world\""), which caused errors in previous compilation.

In addition, we improved the search and support of the vstudio environment, and solved the problem of compilation failure caused by Chinese in the user's home directory and environment variables.

We have also improved the llvm toolchain to solve the problem of the lack of isysroot configuration when using the llvm tool chain under macOS if xcode is not installed, and the occasional failure of the header file dependency compilation under msvc.

Changelog

New features

#1035: The graphics configuration menu fully supports mouse events, and support scroll bar
#1098: Support stdin for os.execv
#1079: Add autoupdate plugin rule for vsxmake, add_rules("plugin.vsxmake.autoupdate")
Add xmake f --vs_runtime=MT and set_runtimes("MT") to set vs runtime for targets and packages
#1032: Support to enum registry keys and values
#1026: Support group for vs/vsxmake project
#1178: Add add_requireconfs() api to rewrite configs of depend packages
#1043: Add luarocks.module rule for luarocks-build-xmake
#1190: Support for Apple Silicon (macOS ARM)
#1145: Support Qt deploy for Windows, thanks @SirLynix

Change

#1072: Fix and improve to parse cl deps
Support utf8 for ui modules and xmake f --menu
Improve to support zig on macOS
#1135: Improve multi-toolchain and multi-platforms for targets
#1153: Improve llvm toolchain to support sysroot on macOS
#1071: Improve to generate vs/vsxmake project to support for remote packages
Improve vs/vsxmake project plugin to support global set_arch() setting
#1164: Improve to launch console programs for vsxmake project
#1179: Improve llvm toolchain and add isysroot

Bugs fixed

#1091: Fix incorrect ordering of inherited library dependencies
#1105: Fix c++ language intellisense for vsxmake
#1132: Fix TrimEnd bug for vsxmake
#1142: Fix git not found when installing packages
Fix macos.version bug for macOS Big Sur
#1084: Fix add_defines() bug (contain spaces)
#1195: Fix unicode problem for vs and improve find_vstudio/os.exec

A modern C/C++ package manager

ruki — Wed, 25 Nov 2020 10:48:37 +0000

Introduction

xrepo is a cross-platform C/C++ package manager based on Xmake.

It is based on the runtime provided by xmake, but it is a complete and independent package management program. Compared with package managers such as vcpkg/homebrew, xrepo can provide C/C++ packages for more platforms and architectures at the same time.

And it also supports multi-version semantic selection. In addition, it is also a decentralized distributed repository. It not only provides the official xmake-repo repository, It also supports users to build multiple private repositorys.

At the same time, xrepo also supports installing packages from third-party package managers such as vcpkg/homebrew/conan, and provides unified and consistent library link information to facilitate integration and docking with third-party projects.

If you want to know more, please refer to: Documents, Github and Gitee

Installation

We only need install xmake to use the xrepo command. About the installation of xmake, we can see: Xmake Installation Document.

Supported platforms

Windows (x86, x64)
macOS (i386, x86_64, arm64)
Linux (i386, x86_64, cross-toolchains ..)
*BSD (i386, x86_64)
Android (x86, x86_64, armeabi, armeabi-v7a, arm64-v8a)
iOS (armv7, armv7s, arm64, i386, x86_64)
MSYS (i386, x86_64)
MinGW (i386, x86_64, arm, arm64)
Cross Toolchains

Supported package repositories

Official package repository xmake-repo (tbox >1.6.1)
User-built repositories
Conan (conan::openssl/1.1.1g)
Vcpkg (vcpkg:ffmpeg)
Homebrew/Linuxbrew (brew::pcre2/libpcre2-8)
Pacman on archlinux/msys2 (pacman::libcurl)
Clib (clib::clibs/bytes@0.0.4)
Dub (dub::log 0.4.3)

Suppory distributed repository

In addition to directly retrieving the installation package from the official repository: xmake-repo.

We can also add any number of self-built repositories, and even completely isolate the external network, and only maintain the installation and integration of private packages on the company's internal network.

Just use the following command to add your own repository address:

$ xrepo add-repo myrepo https://github.com/mygroup/myrepo

Seamless integration with xmake project

add_requires("tbox >1.6.1", "libuv master", "vcpkg::ffmpeg", "brew::pcre2/libpcre2-8")
add_requires("conan::openssl/1.1.1g", {alias = "openssl", optional = true, debug = true})
target("test")
     set_kind("binary")
     add_files("src/*.c")
     add_packages("tbox", "libuv", "vcpkg::ffmpeg", "brew::pcre2/libpcre2-8", "openssl")

The following is the overall architecture and compilation process integrated with xmake.

Get started

Installation package

Basic usage

$ xrepo install zlib tbox

Install the specified version package

$ xrepo install "zlib 1.2.x"
$ xrepo install "zlib >=1.2.0"

Install the specified platform package

$ xrepo install -p iphoneos -a arm64 zlib
$ xrepo install -p android [--ndk=/xxx] zlib
$ xrepo install -p mingw [--mingw=/xxx] zlib
$ xrepo install -p cross --sdk=/xxx/arm-linux-musleabi-cross zlib

Install the debug package

$ xrepo install -m debug zlib

Install the package with dynamic library

$ xrepo install -k shared zlib

Install the specified configuration package

$ xrepo install -f "vs_runtime=MD" zlib
$ xrepo install -f "regex=true,thread=true" boost

Install packages from third-party package manager

$ xrepo install brew::zlib
$ xrepo install vcpkg::zlib
$ xrepo install conan::zlib/1.2.11
$ xrepo install pacman:libpng
$ xrepo install dub:log

Find the library information of the package

$ xrepo fetch pcre2
{
  {
    linkdirs = {
      "/usr/local/Cellar/pcre2/10.33/lib"
    },
    links = {
      "pcre2-8"
    },
    defines = {
      "PCRE2_CODE_UNIT_WIDTH=8"
    },
    includedirs = "/usr/local/Cellar/pcre2/10.33/include"
  }
}

$ xrepo fetch --ldflags openssl
-L/Users/ruki/.xmake/packages/o/openssl/1.1.1/d639b7d6e3244216b403b39df5101abf/lib -lcrypto -lssl

$ xrepo fetch --cflags openssl
-I/Users/ruki/.xmake/packages/o/openssl/1.1.1/d639b7d6e3244216b403b39df5101abf/include

$ xrepo fetch -p [iphoneos|android] --cflags "zlib 1.2.x"
-I/Users/ruki/.xmake/packages/z/zlib/1.2.11/df72d410e7e14391b1a4375d868a240c/include

$ xrepo fetch --cflags --ldflags conan::zlib/1.2.11
-I/Users/ruki/.conan/data/zlib/1.2.11/_/_/package/f74366f76f700cc6e991285892ad7a23c30e6d47/include -L/Users/ruki/.conan/data/zlib/1.2.11/_/_/package/f74366f76f700cc6e991285892ad7a23c30e6d47/lib -lz

Export the installed packages

xrepo can quickly export installed packages, including corresponding library files, header files, etc.

$ xrepo export -o /tmp/output zlib

Search supported packages

$ xrepo search zlib "pcr*"
    zlib:
      -> zlib: A Massively Spiffy Yet Delicately Unobtrusive Compression Library (in xmake-repo)
    pcr*:
      -> pcre2: A Perl Compatible Regular Expressions Library (in xmake-repo)
      -> pcre: A Perl Compatible Regular Expressions Library (in xmake-repo)

Show package environment information

$ xrepo env --show luajit
{
   OLDPWD = "/mnt/tbox",
   HOME = "/home/ruki",
   PATH = "/home/ruki/.xmake/packages/l/luajit/2.1.0-beta3/fbac76d823b844f0b91abf3df0a3bc61/bin:/tmp:/tmp/arm-linux-musleabi-cross/bin:~/.local/bin: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
   TERM = "xterm",
   PWD = "/mnt/xmake",
   XMAKE_PROGRAM_DIR = "/mnt/xmake/xmake",
   HOSTNAME = "e6edd61ff1ab",
   LD_LIBRARY_PATH = "/home/ruki/.xmake/packages/l/luajit/2.1.0-beta3/fbac76d823b844f0b91abf3df0a3bc61/lib",
   SHLVL = "1",
   _ = "/mnt/xmake/scripts/xrepo.sh"
}

Load package environment and run commands

$ xrepo env luajit
LuaJIT 2.1.0-beta3 -- Copyright (C) 2005-2017 Mike Pall. http://luajit.org/
JIT: ON SSE2 SSE3 SSE4.1 BMI2 fold cse dce fwd dse narrow loop abc sink fuse
>

$ xrepo env -b "luajit 2.x" luajit
$ xrepo env -p iphoneos -b "zlib,libpng,luajit 2.x" cmake ..

Show the given package information

$ xrepo info zlib
The package info of project:
    require(zlib):
      -> description: A Massively Spiffy Yet Delicately Unobtrusive Compression Library
      -> version: 1.2.11
      -> urls:
         -> http://zlib.net/zlib-1.2.11.tar.gz
            -> c3e5e9fdd5004dcb542feda5ee4f0ff0744628baf8ed2dd5d66f8ca1197cb1a1
         -> https://downloads.sourceforge.net/project/libpng/zlib/1.2.11/zlib-1.2.11.tar.gz
            -> c3e5e9fdd5004dcb542feda5ee4f0ff0744628baf8ed2dd5d66f8ca1197cb1a1
      -> repo: xmake-repo https://gitee.com/tboox/xmake-repo.git master
      -> cachedir: /Users/ruki/.xmake/cache/packages/2010/z/zlib/1.2.11
      -> installdir: /Users/ruki/.xmake/packages/z/zlib/1.2.11/d639b7d6e3244216b403b39df5101abf
      -> searchdirs:
      -> searchnames: zlib-1.2.11.tar.gz
      -> fetchinfo: 1.2.11, system
          -> version: 1.2.11
          -> links: z
          -> linkdirs: /usr/local/Cellar/zlib/1.2.11/lib
          -> includedirs: /usr/local/Cellar/zlib/1.2.11/include
      -> platforms: iphoneos, mingw@windows, macosx, mingw@linux,macosx, android@linux,macosx, windows, linux
      -> requires:
         -> plat: macosx
         -> arch: x86_64
         -> configs:
            -> debug: false
            -> vs_runtime: MT
            -> shared: false
      -> configs:
      -> configs (builtin):
         -> debug: Enable debug symbols. (default: false)
         -> shared: Enable shared library. (default: false)
         -> cflags: Set the C compiler flags.
         -> cxflags: Set the C/C++ compiler flags.
         -> cxxflags: Set the C++ compiler flags.
         -> asflags: Set the assembler flags.
         -> vs_runtime: Set vs compiler runtime. (default: MT)
            -> values: {"MT","MD"}

xmake v2.3.8 released, Add Intel C++/Fortran Compiler Support

ruki — Sun, 18 Oct 2020 12:47:18 +0000

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, very friendly to novices, can get started quickly in a short time, allowing users to focus more on the actual project development.

In this new version, we have made full platform support for the Intel series of C++ and Fortran compilers, and improved the Wasm tool chain support added in the previous version, and also supported the Qt SDK for Wasm.

In addition, we have also upgraded luajit to the latest v2.1 version. In terms of cross-platform, xmake has also made great improvements and added support for mips64 architecture.

New feature introduction

Add Intel C++ Compiler support

On this version, we have made full platform support for the Intel series of C++ compilers, including icl on windows and icc/icpc under linux/macOS.

To enable the Intel C++ compiler, we only need to switch to the corresponding toolchain through the --toolchain=icc parameter on the system where the Intel compiler is installed.

$ xmake f --toolchain=icc
$ xmake

Add Intel Fortran Compiler support

In the previous version, xmake only supported the gfortran compiler. In this version, we also support the Intel Fortran compiler, which is ifort. We only need to switch to the corresponding ifort tool chain to use it.

$ xmake f --toolchain=ifort
$ xmake

Add Wasm platform and Qt/Wasm support

In the last version, we added the --toolchain=emcc toolchain to support the compilation of wasm programs, but just specifying the toolchain does not adjust the extension of the target program well, for example, for *.js and The file of *.wasm is generated.

In the new version, we continue to add the xmake f -p wasm platform, the built-in emcc tool chain is enabled, and the surrounding configuration has been improved again based on it.

As long as you switch to the wasm platform, xmake will generate *.js and corresponding *.wasm and other target files by default, and additionally generate *.html pages that can load js to run the wasm program.

In addition, we also support Qt SDK for Wasm, for example, we create a Qt QuickApp project.

$ xmake create -t qt.quickapp_static quickapp

Here, we noticed that what we created is a Qt project that requires a static link. Because of the wasm version of the Qt library, we need to force a static link to the program to use it normally.

The content of the generated project file xmake.lua is roughly as follows:

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

includes("qt_add_static_plugins.lua")

target("demo")
    add_rules("qt.quickapp_static")
    add_headerfiles("src/*.h")
    add_files("src/*.cpp")
    add_files("src/qml.qrc")
    add_frameworks("QtQuickControls2", "QtQuickTemplates2")
    qt_add_static_plugins("QtQuick2Plugin", {linkdirs = "qml/QtQuick.2", links = "qtquick2plugin"})
    qt_add_static_plugins("QtQuick2WindowPlugin", {linkdirs = "qml/QtQuick/Window.2", links = "windowplugin"})
    qt_add_static_plugins("QtQuickControls2Plugin", {linkdirs = "qml/QtQuick/Controls.2", links = "qtquickcontrols2plugin"})
    qt_add_static_plugins("QtQuickTemplates2Plugin", {linkdirs = "qml/QtQuick/Templates.2", links = "qtquicktemplates2plugin"})

In the above configuration, in addition to enabling the qt.quickapp_static compilation rules, we also configure some necessary Qt plugins through qt_add_static_plugins.

Next, we only need to switch to the wasm platform and make sure that the Qt SDK is set to complete the compilation.

$ xmake f -p wasm [--qt=~/Qt]
$ xmake

After the compilation is completed, xmake will generate demo.html and the corresponding demo.js/demo.wasm program in the build directory. We can open the demo.html page to run the Qt program we compiled. The display effect is as follows:

For a more detailed description of Qt/Wasm, see: Issue #956

Add Math/Float-point compilation optimization settings

We have added a new set_fpmodels() setting interface, which is used to set the floating-point compilation mode and the compilation abstraction settings for the optimization of mathematical calculations. It provides several commonly used levels such as fast, strict, except, precise, and some Set at the same time, some conflicts, the last setting takes effect.

For the description of these levels, you can refer to the Microsoft document: Specify floating-point behavior

Of course, for other compilers such as gcc/icc, xmake will map to different compilation flags.

set_fpmodels("fast")
set_fpmodels("strict")
set_fpmodels("fast", "except")
set_fpmodels("precise") - default

For details on this, see: Issue #981

Add OpenMP Support

In order to enable the openmp feature more abstractly and simply, we can set it through the newly added c.openmp and c++.openmp rules. In addition, we need additional libomp libraries on linux and macOS, so we can pass ʻAdd_requires("libomp")` for quick reference and integration.

lua add_requires("libomp", {optional = true}) target("loop") set_kind("binary") add_files("src/*.cpp") add_rules("c++.openmp") add_packages("libomp")

If it is c code, you need to enable ʻadd_rules("c.openmp")`. If it is c/c++ mixed compilation, then these two rules must be set.

Add c11/c17 support

In the new version, xmake has also made improvements to set_languages, adding new c11/c17 settings, and at the same time adapting and adapting /std:c11 and /std:c17 provided by the latest version of msvc. stand by.

We only need simple settings:

set_languages("c17")

You can enable the c17 standard to compile, even if the lower version of msvc and other compilers do not support it, xmake will automatically ignore the settings.

Better Mingw support

Regarding this improvement, several aspects are involved. The first is the improvement of the automatic detection of the Mingw SDK root directory under Windows. In most cases, we do not need to configure the --mingw= parameter to specify the path explicitly, and it can also It was automatically detected.

For details on this, see: Issue #977

In addition, in addition to Msys2/Mingw as well as macOS, linux/Mingw, we additionally support llvm-mingw this SDK in the new version, so that we can use mingw to compile the program of arm/arm64 architecture.

$ xmake f -p mingw -a arm64
$ xmake

In addition, in the automatic compilation and integration of remote dependency packages, there are now third-party libraries with cmakelists. Even on the mingw platform, xmake can be automatically compiled and integrated for direct use, which is very fast and convenient.

Recently, in the xmake-repo official C/C++ package repository, we have also added a lot of new libraries that support the mingw platform, which can be used directly .

Better cross-platform operation

We have added support for mips64-based Linux system operation, and improved the stability of xmake under arm/arm64. By incorporating the latest luajit v2.1, we have solved many problems left by luajit, such as the bad of lightuserdata under arm64. Pointer and other issues.

Add macOS Sierra for arm64 support

xmake has also adapted the latest Xcode-beta, and added macOs for arm64 target program compilation support, just switch to the arm64 architecture compilation.

$ xmake f -a arm64 [--xcode=Applications/Xcode-beta.app/]
$ xmake

Of course, the premise is to run under macOS and use the latest Xcode-beta version that supports the Developer Transition Kit (DTK).

Add more C/C++ libraries for the official repository

In the official C/C++ repository of xmake xmake-repo, we have recently added dozens of commonly used C/C++ libraries, and also The libraries of the libx11 series are all included.

Although the warehouse package maintenance workload is huge, the current development trend is also becoming more and more active. We have received more and more users' contributions and improved maintenance to the warehouse package.

And, now our official warehouse can be quickly integrated: linux, macOS, windows, mingw, bsd, msys, iphoneos, android and other eight common platform libraries, to achieve true cross-platform C/C++ remote dependency library integration and use support.

Currently we have included a list of some packages and supporting platforms, you can view from here: PKGLIST.md

We have been working hard to solve the problems of messy C/C++ library ecology and cumbersome integration and use, and provide quick and consistent automatic integration and compilation solutions. xmake not only supports the integration of third-party official warehouse packages such as vcpkg/conan/clib/homebrew, but also We are working hard to improve our self-built official warehouse to achieve a better integrated experience.

for example:

add_requires("tbox >1.6.1", "libuv master", "vcpkg::ffmpeg", "brew::pcre2/libpcre2-8")
add_requires("conan::openssl/1.1.1g", {alias = "openssl", optional = true, debug = true})
target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_packages("tbox", "libuv", "vcpkg::ffmpeg", "brew::pcre2/libpcre2-8", "openssl")

Packages with namespaces such as vcpkg::, brew:: and conan:: will automatically switch to the corresponding third-party package warehouse to download and integrate, and the default tbox >1.6.1 etc. Library, the package provided in the official xmake-repo repository will be used by default.

The usage and integration methods are exactly the same, xmake will automatically download, compile, integrate and link.

For more detailed instructions on the dependency integration of remote packages, we can look at the relevant documentation: Remote dependency library integration and use

At the same time, we also welcome more people to participate to help improve the construction of the C/C++ library ecology, and provide a concise and consistent library experience. I believe that C/C++ package management and library ecology are not worse than Rust/Go.

More release version installation support

In the new version, we submitted xmake to the Ubuntu PPA source, so in addition to the existing script installation method, we can also quickly install xmake through apt.

sudo add-apt-repository ppa:xmake-io/xmake
sudo apt update
sudo apt install xmake

At the same time, we also submitted the package to the Copr package management repository, so that we can also quickly install xmake through dnf in Fedora, RHEL, OpenSUSE, CentOS and other distributions.

sudo dnf copr enable waruqi/xmake
sudo dnf install xmake

Changelog

New features

#955: Add zig project templates
#956: Add wasm platform and support Qt/Wasm SDK
Upgrade luajit vm and support for runing on mips64 device
#972: Add depend.on_changed() api to simplify adding dependent files
#981: Add set_fpmodels() for math optimization mode
#980: Support Intel C/C++ and Fortran Compiler
#986: Support for c11 and c17 for MSVC Version 16.8 and Above
#979: Add Abstraction for OpenMP. add_rules("c++.openmp")

Change

#958: Improve mingw platform to support llvm-mingw toolchain
Improve add_requires("zlib~xxx") to support for installing multi-packages at same time
#977: Improve find_mingw for windows
#978: Improve toolchain flags order
Improve Xcode toolchain to support for macOS/arm64

Bugs fixed

#951: Fix emcc support for windows
#992: Fix filelock bug

xmake v2.3.7 released, Add tinyc and emscripten toolchains

ruki — Tue, 15 Sep 2020 13:46:34 +0000

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, very friendly to novices, can get started quickly in a short time, allowing users to focus more on the 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 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, 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 also 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.

New feature introduction

More diverse installation methods

In the new version, we submitted the xmake installation package to windows winget and ubuntu ppa repositories, we can install xmake more conveniently and quickly.

Winget installation

winget install xmake

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 for other platforms, see: Installation Document.

Richer toolchain 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

In the new version, we also provide two additional installation packages, built-in and integrated TinyC compilation environment, the entire installation package only needs 5M, and also contains winsdk api.

The installation package can be found in the github/releases directory of xmake.

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 view all toolchains supported by xmake, we can execute the following command, and the compilation configuration of xmake f -p cross --sdk=/xxx can support more general cross toolchains.

$ 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 improvement

The so-called trybuild mode is a feature introduced by xmake that adapts to existing third-party build systems, because most 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 relatively high for configuration.

Although the configuration of xmake is very easy to use, there is no need to change the build system for projects that have been stably maintained. xmake is mainly used for the construction and maintenance of some new projects.

Based on this background, xmake adopts the trybuild compilation mode, which is the so-called trial compilation mode, which automatically detects the build system of third-party projects. If it detects that the project is maintained by autotools, it will automatically call ./configure; make to compile.

If a project maintained by cmake is detected, cmake is automatically called to generate makefile/build.ninja to compile. For users who use xmake, the compilation can always be completed by just executing the command xmake, 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 detects the autotools build system, it will prompt the user if you need to try to call autotools to compile. After typing y to confirm, you can directly complete the compilation. For cmake projects, you only need to execute the same xmake command.

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 with xmake -r to directly recompile, docked with xmake clean to achieve unified file cleaning, and docked with xmake -v to achieve unified detailed compilation command viewing.

TryBuild's cross-compilation support

If it's just the compilation of the current host platform, you might say, what's the matter, cmake also has cmake --build . to compile directly, it is not too troublesome.

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

When we only need to configure, enable cmake's try-compilation mode through --trybuild=cmake, and then switch to the corresponding platform through -p android/iphoneos/mingw, dock the corresponding SDK, and you can use the same method To quickly implement cross-compilation, even if this project is maintained by cmake.

The user does not need to be concerned. If you use cmake to transfer the configuration of different toolchains, xmake will automatically handle it for you. You only need to execute xmake to compile, or execute xmake -r to recompile, or view compilation detailsxmake -v.

In addition, you can quickly switch the build architecture by xmake f -p iphoneos -a arm64 --trybuild=cmake.

Finally, we need to explain that although 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 projects.

In this way, there is no need to compile with trybuild, and xmake will support cross-compilation more perfectly, because internal xmake will directly compile the project without calling cmake, autotools and other tools, for example:

xmake f -p iphoneos
xmake

xmake f -p android --ndk=/xxx
xmake

As you can see, this time we omit the --trybuild=cmake parameter, because we don’t need it, we compile directly. At this time, xmake is equivalent to independent make/ninja and does not rely on make at all, and the compilation speed is also Can be completely comparable to 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

In this version, we have also made some improvements to the integration of remote dependency packages. For example, you can switch to private network mode by configuring xmake g --network=private.

This is mainly used for some company's internal network through xmake's self-built package management warehouse to achieve closed C/C++ dependency package integration, and will not rely on packages from the official warehouse provided by xmake.

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 by the apt command under the ubuntu system is also supported, while the previous version can only support downloading and installing from the Qt official website The Qt SDK environment.

Changelog

New features

#2941: Add support for winget
Add xmake-tinyc installer without msvc compiler for windows
Add tinyc compiler toolchain
Add emcc compiler toolchain (emscripten) to compiling to asm.js and WebAssembly
#947: Add xmake g --network=private to enable the private network

Change

#907: Improve to the linker optimization for msvc
Improve to detect qt sdk environment
#918: Improve to support cuda11 toolchains
Improve Qt support for ubuntu/apt
Improve CMake project generator
#931: Support to export packages with all dependences
#930: Support to download package without version list directly
#927: Support to switch arm/thumb mode for android ndk
Improve trybuild/cmake to support android/mingw/iphoneos/watchos toolchains

Bugs fixed

#903: Fix install vcpkg packages fails
#912: Fix the custom toolchain
#914: Fix bad light userdata pointer for lua on some aarch64 devices

xmake v2.3.6 released, Support fortran compilation and go dlang package dependences

ruki — Thu, 30 Jul 2020 15:37:33 +0000

This version focuses on some improvements to the support of other languages, such as fortran compilation support, experimental support for zig language, and third-party dependency package support and cross-compilation support for golang/dlang.

Although, xmake focuses on c/c++ build support, other languages support xmake will also make some improvements from time to time. Its main purpose is not to replace their official build system, but only to support mixed compilation with c/c++ , To better serve c/c++ projects,
After all, some c/c++ projects still occasionally call code interfaces of other languages, such as mixed calls with languages such as cuda, dlang, objc, swift, asm, etc., so xmake still provides some basic compilation support for them.

In addition, regarding c/c++, we also support the header file dependency format of the new /sourceDependencies xxx.json output in the vs preview version (this is more reliable and stable for multi-language header file dependency detection).

Introduction of New Features

Fortran language compilation support

Starting from this version, we have fully supported the use of the gfortran compiler to compile fortran projects, we can quickly create an empty project based on fortran by using the following command:

$ xmake create -l fortran -t console test

Its xmake.lua content is as follows:

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

target("test")
    set_kind("binary")
    add_files("src/*.f90")

More code examples can be viewed here: Fortran Examples

Zig language experimental support

Note: At present, this language xmake is still in the experimental support stage, and it is not perfect. For example, it is not supported on windows, and dynamic library compilation under linux/macOS is not yet supported. Please evaluate and use it yourself.

We can use the following configuration method to try and experience, at least the console and static library programs under linux/macOS can still run.

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

target("test")
    set_kind("binary")
    add_files("src/*.zig")

As for why windows does not support it, please refer to the issues I mentioned to zig earlier, #5825

The dynamic library does not support it because I have some pitfalls (the dynamic library generated by zig will automatically append .0.0.0), see: issue 5827

In addition, I lay down in other pits. I personally feel that there are a lot of pits, so I'm still in the experimental stage for the time being, and I will look at it later.

For more examples, see: Zig Examples

Go dependency package and cross compilation support

The new version of xmake continues to make some improvements to the go build support, such as cross-compilation of go. For example, we can compile windows programs on macOS and linux:

$ xmake f -p windows -a x86

In addition, the new version also initially supports the third-party dependency package management of go:

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

add_requires("go::github.com/sirupsen/logrus", {alias = "logrus"})
add_requires("go::golang.org/x/sys/internal/unsafeheader", {alias = "unsafeheader"})
if is_plat("windows") then
    add_requires("go::golang.org/x/sys/windows", {alias = "syshost"})
else
    add_requires("go::golang.org/x/sys/unix", {alias = "syshost"})
end

target("test")
    set_kind("binary")
    add_files("src/*.go")
    add_packages("logrus", "syshost", "unsafeheader")

However, there are still some imperfections. For example, all cascading dependency packages must be manually configured at present, which will be a bit more cumbersome and needs to be improved in the future.

For more examples, see: Go Examples

Dlang/Dub dependency package support

xmake also supports dlang's dub package management, which can quickly integrate dlang's third-party dependency packages:


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

add_requires("dub::log 0.4.3", {alias = "log"})
add_requires("dub::dateparser", {alias = "dateparser"})
add_requires("dub::emsi_containers", {alias = "emsi_containers"})
add_requires("dub::stdx-allocator", {alias = "stdx-allocator"})
add_requires("dub::mir-core", {alias = "mir-core"})

target("test")
    set_kind("binary")
    add_files("src/*.d")
    add_packages("log", "dateparser", "emsi_containers", "stdx-allocator", "mir-cor