This version focuses on making some improvements to the support of other languages, such as adding fortran compilation support, experimental support for zig language, and adding third-party dependency package support and cross-compilation support for golang/dlang.
Although, xmake focuses on the build support of c/c++, the support of other languages 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, in some c/c++ projects, code interfaces of other languages are still occasionally called, such as mixed calls with languages such as cuda, dlang, objc, swift, asm, etc., so xmake will still Do some basic compilation support for them.
In addition, regarding c/c++, we also support the new /sourceDependencies xxx.jsonoutput header file dependency format in the vs preview version (this is more reliable and stable for header file dependency detection in multiple languages).
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 be automatically appended .0.0.0). For details, see: issue 5827
In addition, I lay down in other pits. I personally feel that there are a lot of pits, so I am still in the experimental stage for the time being.
For more examples, see: Zig Examples
Go dependency packages 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 provides preliminary support for go's third-party dependency package management:
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 little 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 of msvc depends on /showIncludesthe output content that usually needs to be parsed , and the includes file list inside is extracted to deal with the dependency compilation problem, but cl.exe does a very bad job of this output, the includes information and the compilation output are mixed.
It is very unfriendly to build tools to deal with dependency analysis, especially in a multi-language environment, how to judge is includes, you need Note: including file:to judge the extraction by the preceding string, but in Chinese, it is 注意: 包含文件:,
if it is changed to Japanese, it is also in Japanese Prefix strings, encoding format issues, and hard-coding issues lead to parsing and processing, which is not perfect anyway.
Regarding this point, in the latest vs2019 preview version, Microsoft has finally made improvements to the alignment. Through the new /sourceDependencies xxx.jsoncompilation option, the includes dependency information can be better output, which is convenient for analysis and extraction in a multi-language 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 content looks 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 core.base.jsonhandles json parsing by adding a new built-in module, which makes it easy to parse 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 is still used /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 pass cmake supports it in disguise, xmake will automatically call cmake internally to transfer the generated results, there is no difference in use for users, just make sure that cmake has been installed:
$ xmake project -k xcode
!> After we have time, we will re-implement each more complete xcode output plug-in, and welcome everyone to help contribute.
xmake-vscode plugin intellisense support
Recently, we have also updated the xmake-vscode plug-in, which is automatically generated compile_commands.jsonto the .vscodedirectory of the current project , and then we only need to configure .vscode/c_cpp_properties.jsonit to associate this .vscode/compile_commands.jsonpath
to realize the automatic prompt of intellisense, and synchronize the configuration information such as includedirs in xmake.lua. .
As for how to generate it 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",
}
],
update content
New features
- Add the xcode project generator plug-in,
xmake project -k cmake(currently generated by cmake) - #870 : Support gfortran compiler
- #887 : Support zig compiler
- #893 : Add json module
- #898 : Improve golang project construction and support cross-compilation
- #275 : Support go package manager to integrate third-party go dependency packages
- #581 : Support dub package manager to integrate third-party dlang dependency packages