This release highlights some improvements to support for other languages, such as FORTRAN compilation support, experimental support for zig, third-party dependencies for Golang/Dlang, and cross-compilation support.

Although Xmake focuses on C/C ++ build support, other languages also make improvements from time to time. The main purpose of Xmake is not to replace their own official build systems, but to support mixed compilation with C/C ++ to better serve C/C ++ projects. After all, some C/C ++ projects, There will still be occasional calls to code interfaces in other languages, such as cudA, Dlang, OBJC, Swift, ASM, etc., so Xmake will still provide some basic compilation support for them.

In addition to c/ C ++ support for the new /sourceDependencies XXX. Json output header dependency format in the VS preview (this makes header dependency detection more reliable in multiple languages).

  • Program source code
  • The official documentation

New Features

Fortran language compilation support

As of this release, we have fully supported compiling FORTRAN projects using the GForTRAN compiler. We can quickly create a forTRAN-based empty project by using the following command:

$ xmake create -l fortran -t console test
Copy the code

Its xmake. Lua contents are as follows:

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

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

More code Examples can be seen here: Fortran Examples

Zig language experimental support

Note: This language xmake is still in the experimental support stage, it is not perfect, such as: Windows does not support, Linux /macOS dynamic library compilation is not supported, please use your own evaluation.

Console and static Library programs can run on Linux /macOS, at least, for a taste of what can be done.

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

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

For details on why Windows doesn’t support it, see my earlier zig issues, #5825

The dynamic library does not support it, also because I have some holes (zig generated dynamic library will automatically append.0.0.0), see issue 5827 for details

In addition, I also lay down other pits. Personally, I feel there are too many pits, so I am still in the experimental stage for the time being, and I will see again after a period of time.

See Zig Examples for more Examples

Go relies on package and cross-compilation support

Xmake continues with some improvements to 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
Copy the code

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")
Copy the code

However, there are still some imperfections, such as having to manually configure all cascading dependency packages, which is a little more cumbersome and needs to be improved.

See: Go Examples for more Examples

Dlang/Dub dependency package support

Xmake also provides support for dlang duB package management, which enables quick integration of dlang’s third-party dependencies:

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")
Copy the code

Cl.exe new header files depend on file support

MSVC header dependencies usually need to parse the /showIncludes output and extract the list of includes files to handle dependency compilations. However, cl.exe does a poor job with this output because the includes information is mixed with the compiled output.

Note: including file: includes: includes: includes: includes: includes: includes: includes: includes: includes: includes: includes: includes Include file: if change to Japanese environment, it is Japanese prefix string, encoding format problems, hard coding problems lead to parsing, always not very perfect.

In the latest vs2019 preview, Microsoft has improved alignment with a new /sourceDependencies xxx.json compiler option that outputs more includes dependencies for parsing in multiple languages.

In addition, the output of this new option is isolated to a separate JSON file instead of being mixed with the compile output, and does not have to parse the compilation errors, warning messages, and includes list information in a painful way.

The output should look something 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".Copy the code

In the new version, Xmake has added a built-in core.base.json module to handle JSON parsing, which makes it easy to parse and support new header dependencies. This mode is preferred (if supported in the new version of CL, the old version still uses /showIncludes).

Xcode plug-in generation support

At present, we have no time to implement the generation of Xcode project by ourselves, but it does not mean that we do not support it, because Xmake supports the generation of cmakelists. TXT file, while cmake supports the generation of Xcode project file. Before the official implementation, we can also support it through cmake. Xmake will automatically call cmake internally to generate the result, which makes no difference to the user, just make sure cmake is installed:

$ xmake project -k xcode
Copy the code

! > < p style = “max-width: 100%; clear: both;

Intellisense support for xmake-vscode plug-in

Recently, we also updated the xmake-vscode plugin to automatically generate compile_commands.json to the.vscode directory of the current project. Then we just need to configure.vscode/c_cpp_properties.json to associate the.vscode/compile_commands.json path to intellisense auto-prompt. Synchronize includedirs and other configuration information in xmake. Lua.

As for, specific how to generate c_cpp_properties, there is a detailed official documentation: code.visualstudio.com/docs/cpp/co…

The main configuration items are as follows:

  "configurations": [{"compileCommands": ".vscode/compile_commands.json",}],Copy the code

Update the content

New features

  • Add xcode project Generator plug-in,xmake project -k cmake(Currently generated using cmake)
  • #870: Support for gFORtran compilers
  • #887: Support for zig compiler
  • #893: Add json module
  • #898: Improved Golang project build to support cross-compilation
  • #275: Support for go package manager to integrate third-party GO dependencies
  • #581: Support duB package manager to integrate third party Dlang dependencies

To improve the

  • # 868Support for the new cl.exe header file dependent output file format,/sourceDependencies xxx.json
  • #902: Improved cross-compilation toolchain

Tboox.org/cn/2020/07/…