> On 15 May 2017, at 11:58, David Hart <da...@hartbit.com> wrote: > >> >> 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? >
I am not familiar with Cargo. But pretty much any example you can site is something I dislike ;-) On the command line I like single-purpose commands since that makes creating and understanding scripts easier. Maybe that is just me… Rien. > 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
