> On 15 May 2017, at 10:12, David Hart <[email protected]> wrote:
> 
> 
>> On 15 May 2017, at 10:03, Rien <[email protected]> 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.

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 
>>> <[email protected]> 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
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to