[swift-build-dev] [swift-evolution] [Pitch] Swift run Command

[Rien]

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.

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