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:
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-core")
cl.exe new header file dependent file support
The header file dependency of msvc usually needs to parse the output content of /showIncludes and extract the includes file list inside to handle the dependency compilation problem. However, cl.exe does a very bad job of this output. The includes information and compilation output are Mixed together.
It is very unfriendly to build tools to handle dependency analysis, especially in a multi-language environment, how to judge is includes, you need to judge the extraction through the preceding Note: including file: string, but in Chinese, it is Note: include File: ,
If you change to the Japanese environment, it is also a Japanese prefix string, the encoding format problems, hard-coding problems, and the parsing and processing are not perfect.
Regarding this point, in the latest vs2019 preview version, Microsoft has finally made improvements to the alignment. Through the new /sourceDependencies xxx.json compilation option, the includes dependency information can be better output, which is convenient for analysis and extraction in a multilingual environment.
In addition, the output of this new option is independent of a separate json file, and finally is not mixed with the compilation output, and finally there is no need to parse and separate compilation errors, warning messages, and includes list information.
The output will look like this:
{
"Version": "1.0",
"Data": {
"Source": "z:\\personal\\tbox\\src\\tbox\\tbox.c",
"Includes": [
"z:\\personal\\tbox\\src\\tbox\\tbox.h",
"z:\\personal\\tbox\\src\\tbox\\prefix.h",
"z:\\personal\\tbox\\src\\tbox\\prefix\\prefix.h",
"z:\\personal\\tbox\\src\\tbox\\prefix\\config.h",
"z:\\personal\\tbox\\src\\tbox\\config.h",
...
In the new version, xmake handles json parsing by adding a builtin core.base.json module, which can easily analyze and support the new header file dependent data. This mode is preferred (if cl is supported by the new version) , The old version of cl still uses /showIncludes).
Xcode plugin generation support
At present, we have no time to implement the generation of xcode projects by ourselves, but it does not mean that it is not supported, because xmake supports the generation of cmakelists.txt files, and cmake supports the generation of xcode project files. Before the official implementation, We can also support it in disguise through cmake, xmake will automatically call cmake internally to transfer the generated results, there is no difference in use for users, just make sure that cmake is installed:
$ xmake project -k xcode
!> After we have time, we will re-implement each more complete xcode output plugin by ourselves, and welcome everyone to contribute.
Support intellisense for xmake-vscode plugin
Recently, we also updated the xmake-vscode plugin, by automatically generating compile_commands.json to the current project’s .vscode directory, Then we only need to configure .vscode/c_cpp_properties.json and associate this .vscode/compile_commands.json path in it
Can realize intellisense automatic prompt, synchronize the configuration information such as includedirs in xmake.lua.
As for how to generate c_cpp_properties, there are detailed instructions in the official document: https://code.visualstudio.com/docs/cpp/configure-intellisense-crosscompilation
The main configuration items inside:
"configurations": [
{
"compileCommands": ".vscode/compile_commands.json",
}
],
Changlog
New features
- Add
xmake project -k xcodegenerator (use cmake) - #870: Support gfortran compiler
- #887: Support zig compiler
- #893: Add json module
- #898: Support cross-compilation for golang
- #275: Support go package manager to install go packages
- #581: Support dub package manager to install dlang packages