<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><blockquote type="cite" class=""><div class="">On 15 May 2017, at 10:03, Rien &lt;<a href="mailto:Rien@balancingrock.nl" class="">Rien@balancingrock.nl</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I always wondered why it did not exist already ;-)<br class=""><br class="">However, I am not sure if I like the “auto build” aspect. For example I may have started working on a change, but quickly want to verify the exact old behaviour. Then I want to run the old build again. While this proposal does not make this impossible, it makes it more cumbersome as I now need to remember when to use the old method and the new run command.<br class=""></div></div></blockquote><div><br class=""></div><div>There is a <b class="">—skip-build</b> option to run without building. I think it’s better this way before (1) building before running seems like the most common scenario and (2) it mirrors how it works with <b class="">swift test</b>. Having it work the other way round for <b class="">run</b> would be very confusing IMHO.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Having a build option would make more sense imo, i.e:<br class="">$ swift run <br class="">Always runs the present build<br class="">$ swift run -b<br class="">Builds first, then runs the new build.<br class=""><br class=""><br class="">Regards,<br class="">Rien<br class=""><br class="">Site: <a href="http://balancingrock.nl" class="">http://balancingrock.nl</a><br class="">Blog: <a href="http://swiftrien.blogspot.com" class="">http://swiftrien.blogspot.com</a><br class="">Github: <a href="http://github.com/Balancingrock" class="">http://github.com/Balancingrock</a><br class="">Project: <a href="http://swiftfire.nl" class="">http://swiftfire.nl</a> - A server for websites build in Swift<br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On 15 May 2017, at 09:47, David Hart via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class="">Hello evolution (and build-dev),<br class=""><br class="">I’d like to pitch a QOL proposal to improve the development of command-line Swift Packages by introducing a `swift run` command. I’d value any feedback before moving forward.<br class=""><br class=""><a href="https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md" class="">https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md</a><br class=""><br class="">Regards,<br class="">David.<br class=""><br class="">Swift run Command<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>• Proposal: SE-XXXX<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>• Authors: David Hart<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>• Review Manager: TBD<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>• Status: TBD<br class="">Introduction<br class=""><br class="">The proposal introduces a new swift run command to build and run an executable defined in the current package.<br class=""><br class="">Motivation<br class=""><br class="">It is common to want to build and run an executable during development. For now, one must first build it and then execute it from the build folder:<br class=""><br class="">$ swift build<br class="">$ .build/debug/myexecutable<br class=""><br class="">In Swift 4, the Swift Package Manager will build to a different path, containing a platform sub-folder (.build/macosx-x86_64/debug for mac and .build/linux-x86_64/debug for linux), making it more cumbersome to run the executable from the command line.<br class=""><br class="">To improve the development workflow, the proposal suggest introducing a new first-level swift run command that will build if necessary and then run an executable defined in the Package.swift manifest, replacing the above steps into just one.<br class=""><br class="">Proposed solution<br class=""><br class="">The swift run command would be defined as:<br class=""><br class="">$ swift run --help<br class="">OVERVIEW: Build and run executable<br class=""><br class="">USAGE: swift run [options] [executable] [-- arguments]<br class=""><br class="">OPTIONS:<br class=""> &nbsp;--build-path &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Specify build/cache directory [default: ./.build]<br class=""> &nbsp;--chdir, -C &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Change working directory before any other operation<br class=""> &nbsp;--in-dir, -I &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Change working directory before running the executable<br class=""> &nbsp;--color &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Specify color mode (auto<br class="">|always|<br class="">never) [default: auto]<br class=""> &nbsp;--configuration, -c &nbsp;&nbsp;&nbsp;&nbsp;Build with configuration (debug<br class="">|<br class="">release) [default: debug]<br class=""> &nbsp;--enable-prefetching &nbsp;&nbsp;&nbsp;Enable prefetching <br class="">in<br class=""> resolver<br class=""> &nbsp;--skip-build &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Skip building the executable product<br class=""> &nbsp;--verbose, -v &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Increase verbosity of informational output<br class=""> &nbsp;-Xcc &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Pass flag through to all C compiler invocations<br class=""> &nbsp;-Xlinker &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Pass flag through to all linker invocations<br class=""> &nbsp;-Xswiftc &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Pass flag through to all Swift compiler invocations<br class=""> &nbsp;--help &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Display available options<br class=""><br class="">If needed, the command will build the product before running it. As a result, it can be passed any options swift buildaccepts. As for swift test, it also accepts an extra --skip-build option to skip the build phase. A new --in-diroption is also introduced to run the executable from another directory.<br class=""><br class="">After the options, the command optionally takes the name of an executable product defined in the Package.swiftmanifest and introduced in SE-0146. If called without an executable and the manifest defines one and only one executable product, it will default to running that one. In any other case, the command fails.<br class=""><br class="">The executable can be called with arguments by prefixing them with a -- to separate them from the executable name.<br class=""><br class="">Alternatives considered<br class=""><br class="">One alternative to the Swift 4 change of build folder would be for the Swift Package Manager to create and update a symlink at .build/debug and .build/release that point to the latest build folder for that configuration. Although that should probably be done to retain backward-compatibility with tools that depended on the build location, it does not completely invalid the usefulness of the run command.<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></body></html>