xmake
/
xmake-docs
зеркало из https://github.com/xmake-io/xmake-docs


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505
							<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>xmake</title>
  <link rel="icon" href="/assets/img/favicon.ico">
  <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />
  <meta name="description" content="Description">
  <meta name="viewport" content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">
  <link href="/assets/npm/github-markdown/github-markdown.min.css" rel="stylesheet">
  <style>
	.markdown-body {
		box-sizing: border-box;
		min-width: 200px;
		max-width: 980px;
		margin: 0 auto;
		padding: 45px;
	}

	@media (max-width: 767px) {
		.markdown-body {
			padding: 15px;
		}
	}
  </style>
</head>
<body>
<article class="markdown-body">
<h4>This is a mirror page, please see the original page: </h4><a href="https://xmake.io/#/guide/syntax_description">https://xmake.io/#/guide/syntax_description</a>
<div id="wwads-panel" class="wwads-cn wwads-vertical wwads-sticky" data-id="239" style="max-width:180px;bottom:20px;right:20px;width:200px;height:260px;background:#fff;position:fixed"></div>
</br>
    <script type="text/javascript" charset="UTF-8" src="https://cdn.wwads.cn/js/makemoney.js" async></script>
<script async type="text/javascript" src="//cdn.carbonads.com/carbon.js?serve=CE7I52QU&placement=xmakeio" id="_carbonads_js"></script>
<style>
#carbonads {
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu,
  Cantarell, "Helvetica Neue", Helvetica, Arial, sans-serif;
}

#carbonads {
  display: flex;
  max-width: 330px;
  background-color: hsl(0, 0%, 98%);
  box-shadow: 0 1px 4px 1px hsla(0, 0%, 0%, .1);
}

#carbonads a {
  color: inherit;
  text-decoration: none;
}

#carbonads a:hover {
  color: inherit;
}

#carbonads span {
  position: relative;
  display: block;
  overflow: hidden;
}

#carbonads .carbon-wrap {
  display: flex;
}

.carbon-img {
  display: block;
  margin: 0;
  line-height: 1;
}

.carbon-img img {
  display: block;
}

.carbon-text {
  font-size: 13px;
  padding: 10px;
  line-height: 1.5;
  text-align: left;
}

.carbon-poweredby {
  display: block;
  padding: 8px 10px;
  background: repeating-linear-gradient(-45deg, transparent, transparent 5px, hsla(0, 0%, 0%, .025) 5px, hsla(0, 0%, 0%, .025) 10px) hsla(203, 11%, 95%, .4);
  text-align: center;
  text-transform: uppercase;
  letter-spacing: .5px;
  font-weight: 600;
  font-size: 9px;
  line-height: 1;
}
</style>
    <h1 id="syntaxdescription">Syntax description</h1>
<p>Xmake&#39;s project description file <code>xmake.lua</code> is based on the lua syntax, but in order to make the project build logic more convenient and concise, Xmake encapsulates it, making writing <code>xmake.lua</code> not as cumbersome as some makefiles.</p>
<p>Basically write a simple project build description, just three lines, for example:</p>
<pre><code class="lang-lua">target("test")
    set_kind("binary")
    add_files("src/*.c")
</code></pre>
<h2 id="configurationseparation">Configuration Separation</h2>
<p>Xmake.lua uses the 80:20 rule (aka <a href="https://en.wikipedia.org/wiki/Pareto_principle">Pareto principle</a>) to implement a two-layer separate configuration of the description domain and the script domain.</p>
<p>What is the 80:20 rule? In short, most of the project configuration, 80% of the cases, are basic basic configurations, such as: <code>add_cxflags</code>, <code>add_links</code>, etc.<br>Only less than 20% of the space needs to be extra complex to meet some special configuration needs.</p>
<p>The remaining 20% of the configuration is usually more complicated. if it is directly flooded in the whole <code>xmake.lua</code>, the whole project configuration will be very confusing and very unreadable.</p>
<p>Therefore, Xmake isolates 80% of simple configuration and 20% of complex configuration by describing two different configurations of domain and script domain, making the whole <code>xmake.lua</code> look very clear and intuitive, readable and maintainable. Get the best.</p>
<h3 id="descriptionscope">Description Scope</h3>
<p>For beginners who are just getting started, or just to maintain some simple small projects, the requirements are fully met by describing the configuration completely. What is the description domain? It looks like this:</p>
<pre><code class="lang-lua">target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_defines("DEBUG")
    add_syslinks("pthread")
</code></pre>
<p>At first glance, it is actually a configuration set of <code>set_xxx</code>/<code>add_xxx</code>. for the novice, you can not use it as a lua script, just as an ordinary, but there are some basic rules configuration files.</p>
<p>if, by looking, there are parentheses, or function calls like scripting languages, then we can also write this (whether with parentheses to see personal preferences):</p>
<pre><code class="lang-lua">target "test"
    set_kind "binary"
    add_files "src/*.c"
    add_defines "DEBUG"
    add_syslinks "pthread"
</code></pre>
<p>Is this looking more like a profile? In fact, the description field is a configuration file, similar to the configuration of keys/values such as json, so even if you are not a newcomer to lua, you can quickly get started.</p>
<p>Moreover, for the usual projects, only the various settings of the project are configured by <code>set_xxx/add_xxx</code>, which has fully met the requirements.</p>
<p>This is what I said at the beginning: 80% of the time, you can use the simplest configuration rules to simplify the configuration of the project, improve readability and maintainability, so that users and developers will be very friendly and more intuitive.</p>
<p>What if we want to make some conditional judgments for different platforms and architectures? It doesn&#39;t matter, the description field is in addition to the basic configuration, it also supports conditional judgment, as well as the for loop:</p>
<pre><code class="lang-lua">target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_defines("DEBUG")
    if is_plat("linux", "macosx") then
        add_links("pthread", "m", "dl")
    end
</code></pre>
<pre><code class="lang-lua">target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_defines("DEBUG")
    for _, name in ipairs({"pthread", "m", "dl"}) do
        add_links(name)
    end
</code></pre>
<p>Is this looking a bit like lua? Although, it can usually be regarded as a common configuration problem, but Xmake is based on lua after all, so the description domain still supports the basic language features of lua.</p>
<p>!> However, it should be noted that although the description field supports lua script syntax, try not to write too complicated lua scripts in the description field, such as some time-consuming function calls and for loops.</p>
<p>And in the description field, the main purpose is to set the configuration item, so Xmake does not completely open all module interfaces, many interfaces are forbidden to be called in the description field.<br>Even open callable interfaces are completely read-only, and time-consuming security interfaces such as <code>os.getenv()</code> read some general system information for configuration logic control.</p>
<p>!> Also note that <code>xmake.lua</code> is parsed multiple times to resolve different configuration fields at different stages: for example: <code>option()</code>, <code>target()</code>, etc.</p>
<p>So, don&#39;t think about writing complex lua scripts in the description field of <code>xmake.lua</code>, and don&#39;t call print in the description field to display the information, because it will be executed multiple times, remember: it will be executed multiple times! ! !</p>
<h3 id="scriptscope">Script Scope</h3>
<p>Restrict the description field to write complex lua, all kinds of lua modules and interfaces are not used? How to do? This time is the time for the script domain to appear. If the user is already fully familiar with Xmake&#39;s description domain configuration and feels that some of the special configuration maintenance on the project is not met, then we can do more complex configuration logic in the script domain:</p>
<pre><code class="lang-lua">target("test")
    set_kind("binary")
    add_files("src/*.c")
    on_load(function (target)
        if is_plat("linux", "macosx") then
            target:add("links", "pthread", "m", "dl")
        end
    end)
    after_build(function (target)
        import("core.project.config")
        local targetfile = target:targetfile()
        os.cp(targetfile, path.join(config.buildir(), path.filename(targetfile)))
        print("build %s", targetfile)
    end)
</code></pre>
<p>As long as it is similar: <code>on_xxx</code>, <code>after_xxx</code>, <code>before_xxx</code>, etc. The script inside the function body belongs to the script field.</p>
<p>In the script domain, the user can do anything, Xmake provides an import interface to import various lua modules built into Xmake, and can also import user-supplied lua scripts.</p>
<p>We can implement any function you want to implement in the script domain, even if you write a separate project.</p>
<p>for some script fragments, it is not very bloated, such as the above built-in writing is enough, if you need to implement more complex scripts, do not want to be filled in a <code>xmake.lua</code>, you can separate the script into a separate lua file for maintenance.</p>
<p>E.g:</p>
<pre><code class="lang-lua">target("test")
    set_kind("binary")
    add_files("src/*.c")
    on_load("modules.test.load")
    on_install("modules.test.install")
</code></pre>
<p>We can place the custom scripts in the corresponding directory of <code>xmake.lua</code>, and maintain them independently in <code>modules/test/load.lua</code> and <code>modules/test/install.lua</code>.</p>
<p>In these independent lua scripts, we can also import various built-in modules and custom modules through <a href="/mirror/zh-cn/manual/builtin_modules.html#import">import</a>, just like to write lua, java is no different. .</p>
<p>for the different stages of the script&#39;s domain, <code>on_load</code> is mainly used for target loading, do some dynamic configuration, not like the description field, it will only be executed once!!!</p>
<p>In other stages, there are many, such as: <code>on/after/before</code>_<code>build/install/package/run</code>, etc. See the target api manual section later, so I won’t go into details here.</p>
<h2 id="configurationtype">Configuration Type</h2>
<p>In the description domain configuration, you can configure the configuration fields and configuration items. In the configuration domain, you can configure various configuration items through the interface of <code>set_xxx</code>/<code>add_xxx</code>.</p>
<pre><code class="lang-lua">target("test1")
    set_kind("binary")
    add_files("src/*.c")

target("test2")
    set_kind("binary")
    add_files("src/*.c")
</code></pre>
<p>In the above configuration, the target belongs to the configuration domain, and all the <code>set_xx</code>/<code>add_xxx</code> interface configurations below it belong to the configuration item, which is partially effective for this target.</p>
<p>We can understand it as a local scope, similar to the block block in c:</p>
<pre><code class="lang-c">target("test1") {
    set_kind("binary")
    add_files("src/*.c")
}

target("test2") {
    set_kind("binary")
    add_files("src/*.c")
}
</code></pre>
<p>However, in order to simplify the writing, Xmake stipulates that each newly defined target field starts, and the last configuration field ends automatically. Of course, if the user feels troubled, you can manually configure the leaving domain:</p>
<pre><code class="lang-lua">target("test1")
    set_kind("binary")
    add_files("src/*.c")
target_end()

target("test2")
    set_kind("binary")
    add_files("src/*.c")
target_end()
</code></pre>
<h3 id="configurationscope">Configuration Scope</h3>
<p>Currently available configuration scopes are: <code>target()</code>, <code>option()</code>, <code>task()</code>, <code>package()</code></p>
<p>for a detailed description of each domain, see: <a href="/mirror/manual/project_target.html">API Manual</a></p>
<h3 id="configurationitem">Configuration Item</h3>
<p>As long as the configuration with the words <code>set_xxx</code> and <code>add_xxx</code> is a configuration item, multiple configuration items can be set in one configuration field.</p>
<p>for a description of the configuration items, see: <a href="/mirror/manual/specification.html">Interface Specifications</a></p>
<h2 id="scope">Scope</h2>
<p>The description syntax of Xmake is divided by scope, which is mainly divided into:</p>
<ul>
<li>external scope</li>
<li>Internal scope</li>
<li>Interface scope</li>
</ul>
<p>Which ones belong to the outside and which ones belong to the inside? if you look at the comments below, you know what it is:</p>
<pre><code class="lang-lua">-- external scope
target("test")

    -- external scope
    set_kind("binary")
    add_files("src/*.c")

    on_run(function ()
        -- Internal scope
        end)

    after_package(function ()
        -- Internal scope
        end)

-- external scope
task("hello")

    -- external scope
    on_run(function ()
        -- Internal scope
        end)
</code></pre>
<p>Simply put, all within the custom script <code>function () end</code> belongs to the internal scope, which is the script scope, and all other places belong to the external scope. .</p>
<h3 id="externalscope">external Scope</h3>
<p>For most projects, you don&#39;t need complicated engineering descriptions, and you don&#39;t need custom scripting support. You just need a simple <code>set_xxx</code> or <code>add_xxx</code> to meet your needs.</p>
<p>Then according to the 28th law, 80% of the cases, we only need to write:</p>
<pre><code class="lang-lua">target("test")
    set_kind("static")
    add_files("src/test/*.c")

target("demo")
    add_deps("test")
    set_kind("binary")
    add_links("test")
    add_files("src/demo/*.c")
</code></pre>
<p>No complicated api calls, no complicated variable definitions, and if judgments and for loops. It&#39;s succinct and readable. At a glance, it doesn&#39;t matter if you don&#39;t understand lua grammar.</p>
<p>As a simple description of the syntax, it looks a bit like a function call, you will know how to configure it at a basic point of programming.</p>
<p>In order to be concise and secure, in this scope, many lua built-in apis are not open, especially related to writing files and modifying the operating environment, only providing some basic read-only interfaces, and logical operations.</p>
<p>The current external scope lating lua built-in apis are:</p>
<ul>
<li>table</li>
<li>string</li>
<li>pairs</li>
<li>ipairs</li>
<li>print</li>
<li>os</li>
</ul>
<p>Of course, although the built-in lua api does not provide much, Xmake also provides a lot of extension APIs. It is not much to describe the api. For details, please refer to: <a href="/mirror/manual.html">API Manual</a></p>
<p>There are also some auxiliary apis, for example:</p>
<ul>
<li>dirs: scan to get all the directories in the currently specified path</li>
<li>files: scan to get all the files in the current specified path</li>
<li>format: format string, short version of string.format</li>
</ul>
<p>There are also variable definitions and logical operations that can be used. after all, it is based on lua. The basic syntax is still there. We can switch the compiled files by if:</p>
<pre><code class="lang-lua">target("test")
    set_kind("static")
    if is_plat("iphoneos") then
        add_files("src/test/ios/*.c")
    else
        add_files("src/test/*.c")
    end
</code></pre>
<p>It should be noted that the variable definition is divided into global variables and local variables. The local variables are only valid for the current <code>xmake.lua</code>, and do not affect the child <code>xmake.lua</code>.</p>
<pre><code class="lang-lua">-- local variables, only valid for current xmake.lua
local var1 = 0

-- global variables that affect all subsmake.lua included after includes()
var2 = 1

includes("src")
</code></pre>
<h3 id="internalscope">Internal Scope</h3>
<p>Also known as plug-ins, script scope, provide more complex and flexible script support, generally used to write some custom scripts, plug-in development, custom task tasks, custom modules, etc.</p>
<p>Usually included by <code>function () end</code>, and passed to the <code>on_xxx</code>, <code>before_xxx</code> and <code>after_xxx</code> interfaces, are all self-scoped.</p>
<p>E.g:</p>
<pre><code class="lang-lua">-- custom script
target("hello")
    after_build(function ()
        -- Internal scope
        end)

-- custom tasks, plugins
task("hello")
    on_run(function ()
        -- Internal scope
        end)
</code></pre>
<p>In this scope, not only can you use most lua apis, but you can also use many extension modules provided by Xmake. All extension modules are imported through import.</p>
<p>For details, please refer to: <a href="/mirror/manual/builtin_modules.html#import">import module document</a></p>
<p>Here we give a simple example, after the compilation is complete, ldid signature on the ios target program:</p>
<pre><code class="lang-lua">target("iosdemo")
    set_kind("binary")
    add_files("*.m")
    after_build(function (target)

        -- Execute signature, if it fails, automatically interrupt, giving a highlight error message
        os.run("ldid -S$(projectdir)/entitlements.plist %s", target:targetfile())
    end)
</code></pre>
<p>It should be noted that in the internal scope, all calls are enabled with the exception catching mechanism. if the operation is wrong, Xmake will be automatically interrupted and an error message will be given.</p>
<p>Therefore, the script is written without the cumbersome <code>if retval then</code> judgment, and the script logic is more clear.</p>
<h3 id="interfacescope">Interface Scope</h3>
<p>All descriptions of api settings in the external scope are also scoped. They are called in different places and have different scopes of influence, for example:</p>
<pre><code class="lang-lua">-- global root scope, affecting all targets, including subproject target settings in includes()
add_defines("DEBUG")

-- define or enter the demo target scope (support multiple entry to append settings)
target("demo")
    set_kind("shared")
    add_files("src/*.c")
    -- the current target scope only affects the current target
    add_defines("DEBUG2")

-- option settings, only local settings are supported, not affected by global api settings
option("test")
    -- local scope of the current option
    set_default(false)

-- other target settings, -DDEBUG will also be set
target("demo2")
    set_kind("binary")
    add_files("src/*.c")

-- re-enter the demo target scope
target("demo")
    -- append macro definitions, only valid for the current demo target
    add_defines("DEBUG3")
</code></pre>
<p>Normally, entering another target/option domain setting will automatically leave the previous target/option field, but sometimes in order to compare some scope pollution, we can show off a domain, for example:</p>
<pre><code class="lang-lua">option("test")
    set_default(false)
option_end()

target("demo")
    set_kind("binary")
    add_files("src/*.c")
target_end()
</code></pre>
<p>Call <code>option_end()</code>, <code>target_end()</code> to explicitly leave the current target/option field setting.</p>
<h3 id="scopeindentation">Scope Indentation</h3>
<p>Indentation in xmake.lua is just a specification for more clear distinction. The current setting is for that scope, although it is ok even if it is not indented, but it is not very readable. .</p>
<p>e.g:</p>
<pre><code class="lang-lua">target("xxxx")
    set_kind("binary")
    add_files("*.c")
</code></pre>
<p>with</p>
<pre><code class="lang-lua">target("xxxx")
set_kind("binary")
add_files("*.c")
</code></pre>
<p>The above two methods are the same in effect, but in understanding, the first one is more intuitive. At first glance, you know that <code>add_files</code> is only set for target, not global.</p>
<p>Therefore, proper indentation helps to better maintain <code>xmake.lua</code>.</p>
<p>Finally attached, tbox&#39;s <a href="https://github.com/tboox/tbox/blob/master/src/tbox/xmake.lua">xmake.lua</a> description, for reference only. .</p>
<h3 id="codeformatting">Code formatting</h3>
<p>The default indentation of the description field configuration syntax does not conform to the lua formatting specification, so the lua language server does not support formatting it.</p>
<p>If you want the IDE, the editor, to support formatting indentation of the configuration better, you can do so by writing <code>do end</code> as follows</p>
<pre><code class="lang-lua">target("bar") do
    set_kind("binary")
    add_files("src/*.cpp")
end

target("foo") do
    set_kind("binary")
    add_files("src/*.cpp")
end
</code></pre>
<p>This allows the Lua LSP to format it correctly as standard lua code, whether this is required or not depends on the user&#39;s needs.</p>
<p>If you don&#39;t have a habit of using automatic code formatting, then you don&#39;t need to do this.</p>
<h2 id="multilevelconfiguration">Multi-level Configuration</h2>
<p>In the script field we can import various rich extension modules by import, and in the description field we can introduce the project subdirectory through the <a href="/#/zh-cn/manual/global_interfaces?id=includes">includes</a> interface. </p>
<p>Remember: Xmake&#39;s includes handles the configuration relationship according to the tree structure. The target configuration in <code>xmake.lua</code> in the subdirectory inherits the root domain configuration in the parent <code>xmake.lua</code>, for example:</p>
<p>Currently there are the following project structures:</p>
<pre><code>Projectdir
    - xmake.lua
    - src
      - xmake.lua
</code></pre><p><code>projectdir/xmake.lua</code> is the project&#39;s root <code>xmake.lua</code> configuration, and <code>src/xmake.lua</code> is a sub-configuration of the project.</p>
<p><code>projectdir/xmake.lua</code> content:</p>
<pre><code class="lang-lua">add_defines("ROOT")

target("test1")
    set_kind("binary")
    add_files("src/*.c")
    add_defines("TEST1")

target("test2")
    set_kind("binary")
    add_files("src/*.c")
    add_defines("TEST2")

Includes("src")
</code></pre>
<p>The global root domain is configured with <code>add_defines("ROOT")</code>, which affects all target configurations below, including all target configurations in the <code>sub-xmake.lua</code> of includes, so this is the global total configuration.</p>
<p>The <code>add_defines("TEST1")</code> and <code>add_defines("TEST2")</code> in test1/test2 belong to the local configuration and only take effect on the current target.</p>
<p><code>src/xmake.lua</code> content:</p>
<pre><code class="lang-lua">add_defines("ROOT2")

target("test3")
    set_kind("binary")
    add_files("src/*.c")
    add_defines("TEST3")
</code></pre>
<p>In the <code>src/xmake.lua</code> sub-configuration, there is also a global root domain, configured with <code>add_defines("ROOT2")</code>, which belongs to the sub-configuration root domain and only takes effect on all targets in the current <code>sub-xmake.lua</code>. For the target <code>xmake.lua</code> in the lower level includes the target, because previously said, Xmake is the configuration inheritance relationship of the tree structure.</p>
<p>Therefore, the final configuration results of these targets are:</p>
<pre><code>target("test1"): -DROOT -DTEST1
target("test2"): -DROOT -DTEST2
target("test3"): -DROOT -DROOT2 -DTEST3
</code></pre><h2 id="syntaxsimplification">Syntax simplification</h2>
<p>The configuration field syntax of <code>xmake.lua</code> is very flexible and can be used in a variety of complex and flexible configurations in the relevant domain, but for many streamlined small block configurations, this time is slightly redundant:</p>
<pre><code class="lang-lua">option("test1")
    set_default(true)
    set_showmenu(true)
    set_description("test1 option")

option("test2")
    set_default(true)
    set_showmeu(true)

option("test3")
    set_default("hello")
</code></pre>
<p>Xmake 2.2.6 or later, for the above small block option domain settings, we can simplify the description into a single line:</p>
<pre><code class="lang-lua">option("test1", {default = true, showmenu = true, description = "test1 option"})
option("test2", {default = true, showmenu = true})
option("test3", {default = "hello"})
</code></pre>
<p>In addition to the option field, this simplified writing is also supported for other domains, such as:</p>
<pre><code class="lang-lua">target("demo")
    set_kind("binary")
    add_files("src/*.c")
</code></pre>
<p>Simplified to:</p>
<pre><code class="lang-lua">target("demo", {kind = "binary", files = "src/*.c"})
</code></pre>
<p>or</p>
<pre><code class="lang-lua">target("demo", {
    kind = "binary",
    files = "src/*.c"
})
</code></pre>
<p>Of course, if the configuration requirements are more complicated, or the original multi-line setting method is more convenient, this depends on your own needs to evaluate which method is used.</p>
<h2 id="optionalscopeconfigurationsyntax">Optional Scope Configuration Syntax</h2>
<p>Our default convention for domain configuration syntax, although very concise, is not very friendly to auto-formatted indentation and IDEs.</p>
<pre><code class="lang-lua">target("foo")
    set_kind("binary")
    add_files("src/*.cpp")
target_end()
</code></pre>
<p>Also, it does not automatically end the current target scope, the user needs to explicitly call <code>target_end()</code>.</p>
<p>Although, as we mentioned above, the <code>do end</code> pattern can be used to solve the auto-indentation problem, the problem of needing <code>target_end()</code> still exists.</p>
<pre><code class="lang-lua">target("bar") do
    set_kind("binary")
    add_files("src/*.cpp")
end
target_end()
</code></pre>
<p>In version 2.7.3, we provide a better optional domain configuration syntax to solve the auto-indent, target domain isolation problem, e.g.</p>
<pre><code class="lang-lua">add_defines("ROOT")

target("foo", function ()
    set_kind("binary")
    add_files("src/*.cpp")
    add_defines("FOO")
end)

target("bar", function ()
    set_kind("binary")
    add_files("src/*.cpp")
    add_defines("BAR")
end)
</code></pre>
<p>The foo and bar domains are completely isolated and we can configure other settings between them without affecting them, plus it is very LSP friendly.</p>
</article>
</body>
</html>