I always wondered why it did not exist already ;-) 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.
Having a build option would make more sense imo, i.e: $ swift run Always runs the present build $ swift run -b Builds first, then runs the new build. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl - A server for websites build in Swift > On 15 May 2017, at 09:47, David Hart via swift-evolution > <[email protected]> wrote: > > Hello evolution (and build-dev), > > 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. > > https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md > > Regards, > David. > > Swift run Command > > • Proposal: SE-XXXX > • Authors: David Hart > • Review Manager: TBD > • Status: TBD > Introduction > > The proposal introduces a new swift run command to build and run an > executable defined in the current package. > > Motivation > > 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: > > $ swift build > $ .build/debug/myexecutable > > 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. > > 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. > > Proposed solution > > The swift run command would be defined as: > > $ swift run --help > OVERVIEW: Build and run executable > > USAGE: swift run [options] [executable] [-- arguments] > > OPTIONS: > --build-path Specify build/cache directory [default: ./.build] > --chdir, -C Change working directory before any other operation > --in-dir, -I Change working directory before running the > executable > --color Specify color mode (auto > |always| > never) [default: auto] > --configuration, -c Build with configuration (debug > | > release) [default: debug] > --enable-prefetching Enable prefetching > in > resolver > --skip-build Skip building the executable product > --verbose, -v Increase verbosity of informational output > -Xcc Pass flag through to all C compiler invocations > -Xlinker Pass flag through to all linker invocations > -Xswiftc Pass flag through to all Swift compiler invocations > --help Display available options > > 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. > > 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. > > The executable can be called with arguments by prefixing them with a -- to > separate them from the executable name. > > Alternatives considered > > 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. > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
