这个版本重点对其余语言的反对做了一些改良，比方新增了fortran的编译反对，zig语言的实验性反对，另外对golang/dlang减少了第三方依赖包反对以及穿插编译反对。

尽管，xmake重点关注c/c++的构建反对，然而其余语言的反对xmake也会不定期做一些改良，其次要目标并不是代替它们官网本身的构建零碎，仅仅只是为了反对与c/c++的混合编译，更好的为c/c++我的项目服务，
毕竟有些c/c++我的项目中，还是会偶然调用其余语言的代码接口，比方与cuda, dlang, objc，swift, asm等语言的混合调用，所以xmake还是会对他们做一些基础性的编译反对。

另外，对于c/c++方面，咱们也对vs预览版中新的/sourceDependencies xxx.json输入的头文件依赖格局也做了反对（这对于多语言下，头文件依赖检测会更加的牢靠稳固）。

  • 我的项目源码
  • 官网文档

新个性介绍

Fortran语言编译反对

这个版本开始，咱们曾经齐全反对应用gfortran编译器来编译fortran我的项目，咱们能够通过上面的命令，疾速创立一个基于fortran的空工程：

$ xmake create -l fortran -t console test

它的xmake.lua内容如下：

add_rules("mode.debug", "mode.release")target("test")    set_kind("binary")    add_files("src/*.f90")

更多代码例子能够到这里查看：Fortran Examples

Zig语言实验性反对

注：目前这个语言xmake还在试验性反对阶段，还很不欠缺，比方：windows上不反对，linux/macOS下动静库编译还不反对，请自行评估应用。

咱们能够通过上面的配置形式，尝试性体验下，至多linux/macOS下console和static library程序还是能够跑的。

add_rules("mode.debug", "mode.release")target("test")    set_kind("binary")    add_files("src/*.zig")

至于为啥windows不反对呢，详情见我之前提给zig的issues，#5825

而动静库不反对，也是因为我躺了一些坑（zig生成的动静库会主动追加.0.0.0），详情见：issue 5827

另外还躺了下其余坑，个人感觉坑有点多，所以我临时还是试验阶段，等过段时间再看看。

更多例子见：Zig Examples

Go依赖包和穿插编译反对

新版本xmake对go构建反对持续做了一些改良，比方对go的穿插编译也进行了反对，例如咱们能够在macOS和linux上编译windows程序：

$ xmake f -p windows -a x86

另外，新版本对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"})endtarget("test")    set_kind("binary")    add_files("src/*.go")    add_packages("logrus", "syshost", "unsafeheader")

不过还有一些不欠缺的中央，比方目前必须手动配置所有级联依赖包，会略微繁琐些，后续有待改良。

更多例子见：Go Examples

Dlang/Dub依赖包反对

xmake对dlang的dub包治理也进行了反对，能够疾速集成dlang的第三方依赖包：

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新的头文件依赖文件反对

msvc的头文件依赖通常须要解析/showIncludes的输入内容，提取外面的includes文件列表来解决依赖编译问题，然而呢，cl.exe对这个的输入做的很不好，includes信息和编译输入是混在一起的。

对构建工具解决依赖解析十分不敌对，尤其是多语言环境下，如何判断是includes，须要通过前置的Note: including file: 字符串来判断提取，但中文下，又是留神: 蕴含文件: ，
如果换成日语环境，又是日文的前缀字符串，编码格局问题、硬编码问题导致解析解决上，总归不是很完满。

对于这一点，最新的vs2019预览版中，微软终于对齐做了改良，通过新的/sourceDependencies xxx.json编译选项，能够更好的输入includes依赖信息，不便多语言环境下的解析提取。

另外，这个新选项的输入是独立到独自的json文件中去的，终于不是跟编译输入混一起了，也终于不必苦楚地解析拆散编译谬误、正告信息、includes列表信息了。

输入内容大略长这样：

{    "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",            ...

而新版本中，xmake通过新增内置的core.base.json模块解决json解析，很不便地对新的头文件依赖数据进行解析和反对，优先应用此模式（如果cl是新版本反对的话，老版本cl还是应用/showIncludes）。

Xcode插件生成反对

目前，咱们还没有工夫去本人实现xcode工程的生成，但不代表不反对，因为xmake反对生成cmakelists.txt文件，而cmake是反对xcode工程文件生成的，在官网还没有实现之前，
咱们也能够通过cmake变相反对它，xmake会主动外部调用cmake直达下生成后果，对用户而言应用上没啥区别，只须要确保cmake曾经装置即可：

$ xmake project -k xcode

!> 等之后有工夫，咱们会从新本人实现各更加欠缺的xcode输入插件，也欢送大家帮忙奉献。

xmake-vscode插件intellisense反对

近期，咱们也更新了下xmake-vscode插件，通过主动生成compile_commands.json到以后我的项目的.vscode目录下，而后咱们只须要配置.vscode/c_cpp_properties.json在外面关联上这个.vscode/compile_commands.json门路
就能实现intellisense主动提醒，同步xmake.lua外面的includedirs等配置信息。

至于，具体怎么生成c_cpp_properties，官网文档外面有具体阐明：https://code.visualstudio.com...

外面的次要配置项：

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

更新内容

新个性

  • 增加xcode工程生成器插件，xmake project -k cmake （以后采纳cmake生成）
  • #870: 反对gfortran编译器
  • #887: 反对zig编译器
  • #893: 增加json模块
  • #898: 改良golang我的项目构建，反对穿插编译
  • #275: 反对go包管理器去集成第三方go依赖包
  • #581: 反对dub包管理器去集成第三方dlang依赖包

改良

  • #868: 反对新的cl.exe的头文件依赖输入文件格式，/sourceDependencies xxx.json
  • #902: 改良穿插编译工具链

https://tboox.org/cn/2020/07/...