[swift-build-dev] [swift-evolution] [Pitch] Swift run Command
Xiaodi Wu
xiaodi.wu at gmail.com
Mon May 15 06:23:43 CDT 2017
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 at swift.org> wrote:
>
> > On 15 May 2017, at 11:58, David Hart <david at hartbit.com> wrote:
> >
> >>
> >> On 15 May 2017, at 10:40, Rien <Rien at balancingrock.nl> wrote:
> >>
> >>
> >>> On 15 May 2017, at 10:12, David Hart <david at hartbit.com> wrote:
> >>>
> >>>
> >>>> On 15 May 2017, at 10:03, Rien <Rien at 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 at 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 at swift.org
> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20170515/de8da6f5/attachment.html>
More information about the swift-build-dev
mailing list