In order to make xmake better support cross-compilation, I refactored the entire tool chain in this version to make the tool chain switching more convenient and quick, and now users can easily extend their tool chain in xmake.lua.
Regarding platform support, we have added support for the *BSD system. In addition, this version also adds a ninja theme style to achieve a compilation progress display similar to ninja, for example:
Introduction of new features
Tool chain improvements
Complete separation of tool chain and platform
The previous version, platform and tool chain bound too closely, such as xmake f -p windowsplatforms, the default can only be used to compile msvc, you want to cut or other clang compiler, cross-compiler platform can only go: xmake f -p cross.
But in this case, some windows platform-specific settings are lost, and users can't use it if is_plat("windows") thento judge the windows platform to make specific settings.
In fact, the platform and the tool chain can be completely independent. After the new version is refactored, even the windows platform and any other platform can be easily and quickly switched to other tool chains such as clang, llvm.
$ xmake f -p windows --toolchain=clang
Built-in tool chain
Although the cross-compiler supports all xmake configuration tool chain, also provides a degree of intelligence analysis and detection tool chain, but the general plan how many additional configuration is necessary to add variety to a specific tool chain support, for example, pass some additional --ldflags=, --cxflags=parameters or something.
The new version of xmake has built-in some commonly used toolchains, which can save the complicated configuration process of cross-compiling toolchains. You only need to pass the toolchain name to it --toolchain=xxx.
Switch to the llvm toolchain:
$ xmake f -p cross --toolchain=llvm --sdk="C:\Program Files\LLVM"
$ xmake
Switch to the GNU-RM tool chain:
$ xmake f -p cross --toolchain=gnu-rm --sdk=/xxx/cc-arm-none-eabi-9-2019-q4-major
$ xmake
You can quickly switch to the specified cross-compilation toolchain. For the built-in toolchain, most of the configuration can be omitted. Usually, only the integration is required, --toolchain=and the --sdk=other configurations will be automatically set to ensure that the compilation is normal.
What built-in toolchains does xmake support? We can view it with the following command:
$ 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
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
Synchronous switching of tool chain
The new version of xmake also supports complete synchronous switching of the tool chain. What does this mean?
For example, if we want to switch from the default gcc to clang compilation, we may need to cut some toolsets xmake f --cc=clang --cxx=clang --ld=clang++ --sh=clang++, because the compiler is cut, the corresponding linker, static library archiver and everything have to be cut at the same time.
It is really painful to cut one by one like this, and the author himself can't stand it, so when refactoring the tool chain, this part has also been improved, and now only needs to:
$ xmake f --toolchain=clang
$ xmake
You can completely cut all the clang toolsets as a whole. How to switch back to gcc is also very convenient:
or
$ xmake f --toolchain=gcc
$ xmake
Custom toolchain
In addition, we can also customize the toolchain in xmake.lua, and then xmake f --toolchain=myclangswitch by specifying, for example:
toolchain("myclang")
set_kind("standalone")
set_toolset("cc", "clang")
set_toolset("cxx", "clang", "clang++")
set_toolset("ld", "clang++", "clang")
set_toolset("sh", "clang++", "clang")
set_toolset("ar", "ar")
set_toolset("ex", "ar")
set_toolset("strip", "strip")
set_toolset("mm", "clang")
set_toolset("mxx", "clang", "clang++")
set_toolset("as", "clang")
-- ...
Which is set_toolsetused to set up different tool sets, such as compiler, linker, assembler, etc.
By default, xmake will xmake f --sdk=xxdetect the tool from the SDK parameters. Of course, we can also call each custom toolchain in xmake.lua set_sdk("/xxx/llvm")to write the toolchain SDK address.
For a detailed introduction to this piece, you can go to the custom tool chain chapter to view
For more details: #780
Set up the toolchain for a specific target
In addition to custom toolchains, we can also switch and set different toolchains for a specific target individually. Unlike set_toolset, this interface is an overall switch for the complete toolchain, such as a series of tools such as cc/ld/sh. set.
This is also recommended, because most of the compiler tool chains such as gcc/clang, the compiler and the linker are used together, if you want to cut it, you have to cut it as a whole, and it will be very cumbersome to switch settings separately.
For example, we switch the test target to the two tool chains of clang+yasm:
target("test")
set_kind("binary")
add_files("src/*.c")
set_toolchains("clang", "yasm")
Or it can be set_toolsetused to individually set specific tools in each target's tool chain.
target("test")
set_kind("binary")
set_toolset("cxx", "clang")
set_toolset("ld", "clang++")
ninja build theme
The construction progress style is similar to ninja, with a single-line progress bar, no longer rolling back the progress, users can set according to their preferences.
Except for the different progress display, everything else is the same as the default theme configuration.
$ xmake g --theme=ninja
Set build behavior strategy
Xmake has many default behaviors, such as automatic detection and mapping of flags, cross-target parallel construction, etc. Although it provides a certain amount of intelligent processing, it is difficult to adjust and may not meet the habits and needs of all users.
Therefore, starting from v2.3.4, xmake provides modification settings of the default build strategy, which is open to users to a certain degree of configurability.
The usage is as follows:
set_policy("check.auto_ignore_flags", false)
You only need to set this configuration in the project root domain to disable the automatic detection and ignoring mechanism of flags, and set_policyit can also take effect locally for a specific target.
target("test")
set_policy("check.auto_ignore_flags", false)
!> In addition, if the set policy name is invalid, xmake will also warn you.
If you want to get a list and description of all the policy configurations supported by xmake, you can execute the following command:
$ xmake l core.project.policy.policies
{
"check.auto_map_flags" = {
type = "boolean",
description = "Enable map gcc flags to the current compiler and linker automatically.",
default = true
},
"build.across_targets_in_parallel" = {
type = "boolean",
description = "Enable compile the source files for each target in parallel.",
default = true
},
"check.auto_ignore_flags" = {
type = "boolean",
description = "Enable check and ignore unsupported flags automatically.",
default = true
}
}
check.auto_ignore_flags
By default add_cxflags, xmake will add_ldflagsautomatically detect all the original flags set by the interface. If it detects that the current compiler and linker do not support them, it will automatically ignore them.
This is usually very useful. For example, some optional compilation flags can be compiled normally even if they are not supported, but they are forced to be set up. When other users are compiling, there may be a certain degree of error due to the different support levels of the compiler. Compilation failed.
However, because automatic detection does not guarantee 100% reliability, and sometimes there will be a certain degree of misjudgment, some users do not like this setting (especially for cross-compilation tool chains, which are more prone to failure).
At present, if the detection fails in the v2.3.4 version, there will be warnings to prevent users from lying in pits inexplicably, for example:
warning: add_ldflags("-static") is ignored, please pass `{
force = true}` or call `set_policy("check.auto_ignore_flags", false)` if you want to set it.
According to the prompts, we can analyze and judge by ourselves whether we need to force this flags to be set, one is to pass:
add_ldflags("-static", {force = true})
To display the mandatory setting, skip the automatic detection. This is a very effective and quick way to deal with the occasional flags failure, but for cross-compilation, when a bunch of flags settings cannot be detected, each set the force Too cumbersome.
At this time, we can set_policydirectly disable the default automatic detection behavior for a target or the entire project:
set_policy("check.auto_ignore_flags", false)
target("test")
add_ldflags("-static")
Then we can set various original flags at will, xmake will not automatically detect and ignore them.
check.auto_map_flags
This is another intelligent analysis and processing of flags by xmake . Usually add_links, add_definesthe configuration set by the built-in api of xmake is cross-platform. Different compiler platforms will automatically process the corresponding original flags.
However, in some cases, users still need to set the original compilation link flags through add_cxflags, add_ldflags, and these flags cannot cross compilers well.
Take -O0the compilation optimization flags as an example. Although there set_optimizeare cross-compiler configurations, what if the user sets them directly add_cxflags("-O0")? It can be processed normally under gcc/clang, but it is not supported under msvc
Maybe we can if is_plat() thendeal with it by platform, but it is very cumbersome, so xmake has built-in automatic mapping function of flags.
Based on the popularity of gcc flags, xmake uses the gcc flags naming convention to automatically map it according to different compilations, for example:
add_cxflags("-O0")
This line setting is still under gcc/clang -O0, but if the current msvc compiler is used, it will automatically be mapped to the msvc corresponding -Odcompiler option to disable optimization.
During the whole process, the user is completely unaware, and the cross-compiler can be completed by directly executing xmake.
!> Of course, the current automatic mapping implementation is not very mature, and there is no 100% coverage of all gcc flags, so there are still many flags that have not been mapped.
Some users do not like this automatic mapping behavior, so we can completely disable this default behavior through the following settings:
set_policy("check.auto_map_flags", false)
build.across_targets_in_parallel
This strategy is also enabled by default. It is mainly used to perform parallel builds across targets. Prior to v2.3.3, parallel builds can only target all source files within a single target. For
cross-target compilation, you must wait for the previous target to complete Only when the link is successful can the compilation of the next target be executed, which will affect the compilation speed to a certain extent.
However, the source files of each target can be processed completely in parallel, and finally the link process is executed together. The version after v2.3.3 has passed this optimization, and the build speed has been increased by 30%.
Of course, if the build source files in some special targets depend on the previous target (especially in the case of custom rules, although rarely encountered), we can also disable this optimization behavior through the following settings:
set_policy("build.across_targets_in_parallel", false)
New compilation mode
mode.releasedbg
Add the configuration rules of releasedbg compilation mode for the current project xmake.lua, for example:
add_rules("mode.releasedbg")
!> Compared with the release mode, this mode also enables additional debugging symbols, which is usually very useful.
Is equivalent to:
if is_mode("releasedbg") then
set_symbols("debug")
set_optimize("fastest")
set_strip("all")
end
We can xmake f -m releasedbgswitch to this compilation mode by:
mode.minsizerel
Add configuration rules for minsizerel compilation mode to the current project xmake.lua, for example:
add_rules("mode.minsizerel")
!> Compared with release mode, this mode is more inclined to minimum code compilation optimization, rather than speed priority.
Is equivalent to:
if is_mode("minsizerel") then
set_symbols("hidden")
set_optimize("smallest")
set_strip("all")
end
We can xmake f -m minsizerelswitch to this compilation mode by:
Display specified information and list
Display basic information of xmake itself and the current project
$ xmake show
The information of xmake:
version: 2.3.3+202006011009
host: macosx/x86_64
programdir: /Users/ruki/.local/share/xmake
programfile: /Users/ruki/.local/bin/xmake
globaldir: /Users/ruki/.xmake
tmpdir: /var/folders/32/w9cz0y_14hs19lkbs6v6_fm80000gn/T/.xmake501/200603
workingdir: /Users/ruki/projects/personal/tbox
packagedir: /Users/ruki/.xmake/packages
packagedir(cache): /Users/ruki/.xmake/cache/packages/2006
The information of project: tbox
version: 1.6.5
plat: macosx
arch: x86_64
mode: release
buildir: build
configdir: /Users/ruki/projects/personal/tbox/.xmake/macosx/x86_64
projectdir: /Users/ruki/projects/personal/tbox
projectfile: /Users/ruki/projects/personal/tbox/xmake.lua
Show toolchain list
$ xmake show -l toolchains
xcode Xcode IDE
vs VisualStudio IDE
yasm The Yasm Modular Assembler
clang A C language family frontend for LLVM
...
Display the specified target configuration information
$ xmake show --target=tbox
The information of target(tbox):
kind: static
targetfile: build/macosx/x86_64/release/libtbox.a
rules: mode.release, mode.debug, mode.profile, mode.coverage
options: info, float, wchar, exception, force-utf8, deprecated, xml, zip, hash, regex, coroutine, object, charset, database
packages: mbedtls, polarssl, openssl, pcre2, pcre, zlib, mysql, sqlite3
links: pthread
syslinks: pthread, dl, m, c
cxflags: -Wno-error=deprecated-declarations, -fno-strict-aliasing, -Wno-error=expansion-to-defined, -fno-stack-protector
defines: __tb_small__, __tb_prefix__="tbox"
mxflags: -Wno-error=deprecated-declarations, -fno-strict-aliasing, -Wno-error=expansion-to-defined
headerfiles: src/(tbox/**.h)|**/impl/**.h, src/(tbox/prefix/**/prefix.S), src/(tbox/math/impl/*.h), src/(tbox/utils/impl/*.h), build/macosx/x86_64/release/tbox.config.h
includedirs: src, build/macosx/x86_64/release
at: /Users/ruki/projects/personal/tbox/src/tbox/xmake.lua
sourcebatch(cc): with rule(c.build)
-> src/tbox/string/static_string.c
-> build/.objs/tbox/macosx/x86_64/release/src/tbox/string/static_string.c.o
-> build/.deps/tbox/macosx/x86_64/release/src/tbox/string/static_string.c.o.d
-> src/tbox/platform/sched.c
-> build/.objs/tbox/macosx/x86_64/release/src/tbox/platform/sched.c.o
-> build/.deps/tbox/macosx/x86_64/release/src/tbox/platform/sched.c.o.d
-> src/tbox/stream/stream.c
-> build/.objs/tbox/macosx/x86_64/release/src/tbox/stream/stream.c.o
-> build/.deps/tbox/macosx/x86_64/release/src/tbox/stream/stream.c.o.d
-> src/tbox/utils/base32.c
-> build/.objs/tbox/macosx/x86_64/release/src/tbox/utils/base32.c.o
-> build/.deps/tbox/macosx/x86_64/release/src/tbox/utils/base32.c.o.d
Display a list of built-in compilation modes
$ xmake show -l modes
Display a list of built-in compilation rules
$ xmake show -l rules
Show other information
It's still being improved, see for details: https://github.com/xmake-io/xmake/issues/798
Or run:
$ xmake show --help
update content
New features
- #630 : Support *BSD system, for example: FreeBSD,…
- Add wprint interface to display warning messages
- #784 : Add
set_policy()to modify some built-in policies, such as: disable automatic flags detection and mapping - #780 : Add set_toolchains/set_toolsets for target to achieve more complete toolchain settings, and to achieve the separation of platform and toolchains
- #798 : Add
xmake showplugins to display various information built in xmake - #797 : Add ninja theme style, display ninja style construction progress bar,
xmake g --theme=ninja - #816 : Add mode.releasedbg and mode.minsizerel compilation mode rules
- #819 : Support ansi/vt100 terminal character control
Improve
- #771 : Check the input validity of includedirs, linkdirs and frameworkdirs
- #774 : The
xmake f --menuvisual configuration menu supports window size Resize adjustment - #782 : Add add_cxflags and other configuration flags automatic detection failure prompt
- #808 : Generate cmakelists plugin to add support for add_frameworks
- #820 : Support independent working directory and build directory, keep the project directory completely clean