I agree with David--building before running is the most sensible default, both because of precedent and because it is, by construction, the most common scenario. I would be highly surprised if a _build_ tool offered to run stale code by default without warning me. On Mon, May 15, 2017 at 05:45 Rien via swift-evolution < swift-evolution@swift.org> wrote:
> > > 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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution