共计 3939 个字符，预计需要花费 10 分钟才能阅读完成。
这个版本重点对其余语言的反对做了一些改良，比方新增了 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"})
end
target("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/…
