Xmake provides $(varname) To support the acquisition of built-in variables, such as:
add_cxflags("-I$(buildir)")
It will build the built-in buildir Convert variables to the actual build output directory: -I./ build
These variables can also be supported in custom scripts, such as:
target("test") after_build(target) print("build ok for $(plat)!") end
This will output:
build ok for macosx!
Most of these built-in variables are obtained from cached configuration parameters during configuration, such as:
$ xmake config --plat=macosx
There are also some built-in variables that do not need to be obtained through configuration, such as:
print("$(os)") print("$(host)") print("$(tmpdir)") print("$(curdir)")
These are all to make the syntax of xmake more concise. For example, when copying files, you only need to:
os.cp("$(projectdir)/file", "$(tmpdir)")
Instead of:
--Import project module import("core.project.project") --Copy File os.cp(path.join(project.directory(), "file"), os.tmpdir())
This is complicated, but some complex functions may have to be handled flexibly, depending on the specific requirements..
In addition to built-in variable processing, xmake also supports the running of native shells to handle some functions not supported by xmake built-in
For example, there is a requirement that I use to call pkg-config Get the actual third-party linkbase name. You can do this:
target("test") set_kind("binary") if is_plat("linux") then add_ldflags("$(shell pkg-config --libs sqlite3)") end
Of course, xmake has its own automatic third library detection mechanism, which generally does not need to be so troublesome, and the scripting of Lua itself is already very good..
But this example can show that xmake can be used with some third-party tools through the native shell..
