> On 15 May 2017, at 10:03, Rien <r...@balancingrock.nl> wrote: > > 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.
There is a —skip-build 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 swift test. Having it work the other way round for run would be very confusing IMHO. > 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 >> <swift-evolution@swift.org> 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 >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
