Huge +1 from me, and for having it build by default. Building should be efficient & transparent to the user IMHO.
On Mon, May 15, 2017 at 11:43 AM Robert Widmann via swift-build-dev < [email protected]> wrote: > +1. A very useful feature to have, indeed. > > ~Robert Widmann > > On May 15, 2017, at 1:47 AM, 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 > > <https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md> > - Authors: David Hart <http://github.com/hartbit/> > - Review Manager: TBD > - Status: TBD > > > <https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#introduction> > Introduction > > The proposal introduces a new swift run command to build and run an > executable defined in the current package. > > <https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#motivation> > 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. > > <https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#proposed-solution>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 > <https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/0146-package-manager-product-definitions.md>. > 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. > > <https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#alternatives-considered>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-build-dev mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-build-dev >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
