<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="">--<br class="">Ankit</div></div>

</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 05-Jul-2017, at 2:37 PM, David Hart &lt;<a href="mailto:davidhart@fastmail.com" class="">davidhart@fastmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 5 Jul 2017, at 10:49, Ankit Aggarwal &lt;<a href="mailto:ankit_aggarwal@apple.com" class="">ankit_aggarwal@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">I think all these options make sense. Some comments inline.</div><br class="" style="font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class="">On 05-Jul-2017, at 2:18 AM, David Hart &lt;<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hello mailing-list,<div class=""><br class=""></div><div class="">I’m planning on adding options to the<span class="Apple-converted-space">&nbsp;</span><font face="Menlo" class=""><b class="">swift build</b></font><span class="Apple-converted-space">&nbsp;</span>command to allow building specific targets or products in the package and its dependencies. And allow<span class="Apple-converted-space">&nbsp;</span><font face="Menlo" class=""><b class="">swift run</b></font><span class="Apple-converted-space">&nbsp;</span>to execute arbitrary products in all the package’s dependencies. I’d like to get feedback on those before going forward or not.</div><div class=""><br class=""></div><div class=""><b class="">Motivation</b></div><div class=""><br class=""></div><div class="">The<span class="Apple-converted-space">&nbsp;</span><font face="Menlo" class=""><b class="">swift build</b></font><span class="Apple-converted-space">&nbsp;</span>command builds all the package targets but doesn’t allow building a specific target or a dependency’s product. This can be useful during development when concentrating on a single target.</div><div class=""><br class=""></div><div class="">The<span class="Apple-converted-space">&nbsp;</span><font face="Menlo" class=""><b class="">swift run</b></font><span class="Apple-converted-space">&nbsp;</span>command searches for an executable to run in the package dependency graph but won’t find it unless it is declared as a target dependency, which is rarely the case. For example, a package using the code generation capabilities of the executable product in the&nbsp;<a href="https://github.com/krzysztofzablocki/Sourcery" class="">Sourcery</a>&nbsp;package can’t run it with<span class="Apple-converted-space">&nbsp;</span><font face="Menlo" class=""><b class="">swift run sourcery</b></font><span class="Apple-converted-space">&nbsp;</span>unless the executable is added as a product dependency, linking the executable's module, which doesn't make much sense.</div><div class=""><br class=""></div><div class=""><b class="">Build</b></div><div class=""><br class=""></div><div class="">To solve both issues above, I was planning on adding 3 new options to the<span class="Apple-converted-space">&nbsp;</span><font face="Menlo" class=""><b class="">swift build</b></font><span class="Apple-converted-space">&nbsp;</span>tool:<br class=""><br class=""><font face="Menlo" class="">&nbsp; --target &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Specify target to build<br class="">&nbsp; --product &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Specify product to build from the package or its dependencies<br class="">&nbsp; --package &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Specify the package to build</font><br class=""><br class="">Here are different examples using those options:<br class=""><br class=""><font face="Menlo" class=""># Builds the Basic target from the root package.<br class="">$ swift build —target Basic<br class=""><br class=""># Searches for a product named SwiftyJSON in the root package and its dependencies and builds it.<br class="">$ swift build —product SwiftyJSON<br class=""><br class=""># Builds all products of the Sourcery package dependency.<br class="">$ swift build —package Sourcery<br class=""><br class=""># Builds the sourcery product from the Sourcery package.<br class="">$ swift build —package Sourcery —product sourcery</font><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">These are supposed to be two dashes (--), right?</div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes, sorry :)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class="">To mirror the behavior of products in the package definition format in&nbsp;<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0146-package-manager-product-definitions.md" class="">SE-0146</a>:<br class=""><ul class=""><li class="">The<span class="Apple-converted-space">&nbsp;</span><font face="Menlo" class=""><b class="">--target</b></font><span class="Apple-converted-space">&nbsp;</span>option can not reference targets in dependent packages because they are considered as implementation details.</li></ul></div></div></div></blockquote><div class="">I think it should be allowed to search the entire package graph for the target and not just top level dependencies. The target names are supposed to be unique anyway.&nbsp;</div></div></div></blockquote><div class=""><br class=""></div><div class="">My idea was to limit it to the project’s package (not even on the first-level dependencies) not for a question of uniqueness but to mirror the fact that SE-0146 removed the possibility to depend on other packages targets specifically because they are supposed to be private implementation details (which is great IMHO):</div><div class=""><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><i class="">For example, consider the package for a component that has both a library API and command line tools. Such a&nbsp;package is also likely to be partitioned into a set of core libraries on which both the public library and the command&nbsp;line tools depend, but which should remain a private implementation detail as far as clients are concerned.</i></div></div></blockquote><div style="font-style: italic;" class=""><i class=""><br class=""></i></div>If we permitted <font face="Menlo" class=""><b class="">swift build —target PrivateTargetInOtherPackage</b></font> to build those private implementation details, wouldn’t we put tools which use this functionality in a brittle situation?<br class=""></div></div></blockquote><div><br class=""></div><div>I think SE-0146 is a little different in the way that the manifest file is involved. The manifest file can become invalid if it depends on some private target and that target is removed on a package update. The CLI tool will be used by the end user and doesn't need a lot of "protection".</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><ul class=""><li class="">The<span class="Apple-converted-space">&nbsp;</span><font face="Menlo" class=""><b class="">--product</b></font><span class="Apple-converted-space">&nbsp;</span>option is generally enough to unambiguously reference a product because product names are expected to be unique. If it is not the case, the<span class="Apple-converted-space">&nbsp;</span><font face="Menlo" class=""><b class="">--package</b></font><span class="Apple-converted-space">&nbsp;</span>option is available for disambiguation.</li></ul><div class=""><b class="">Run</b></div><div class=""><br class=""></div>To allow the<span class="Apple-converted-space">&nbsp;</span><font face="Menlo" class=""><b class="">swift run</b></font><span class="Apple-converted-space">&nbsp;</span>command to reference products which are not depended on, the<span class="Apple-converted-space">&nbsp;</span><font face="Menlo" class=""><b class="">swift build --package</b></font><span class="Apple-converted-space">&nbsp;</span>option will also support referencing products which are not depended on. Indeed, as the<span class="Apple-converted-space">&nbsp;</span><font face="Menlo" class=""><b class="">run</b></font><span class="Apple-converted-space">&nbsp;</span>command implicitly runs the<span class="Apple-converted-space">&nbsp;</span><font face="Menlo" class=""><b class="">build</b></font><span class="Apple-converted-space">&nbsp;</span>command, it makes more sense to give both commands to same features.</div><div class=""><br class=""></div><div class="">Thanks in advance for your feedback,</div><div class=""><br class=""></div><div class="">Regards,</div><div class="">David.</div></div></div></blockquote></div><br class="" style="font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="" style="font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><br class=""><br class="">--<br class="">Ankit</div></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>