> On 15 May 2017, at 10:40, Rien <r...@balancingrock.nl> wrote: > > >> On 15 May 2017, at 10:12, David Hart <da...@hartbit.com> wrote: >> >> >>> 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. > > To me this violates the “least surprising use” rule. (Same for ‘test’, even > though it sets a precedence) > Command line execution should either do as it says, or give an error message. > This is quite different from a GUI behaviour: a GUI ‘run’ command should > build if necessary - and indeed Xcode does just that) > I think it’s a mistake to try to mimic GUI behaviour in a command line > environment.
Firstly, there are other precedents. swift build itself will get dependencies if needed. In cargo, the closest equivalent to SwiftPM (i.e., a package manager/build tool for a language that needs a compilation stage) cargo run builds beforehand. Secondly, if we agree that building before running is the most common scenario, why not make it the default? David. > Regards, > Rien. > >> >>> 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
