[Pitch] Swift run Command


(David Hart) #1

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 <https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md>
Authors: David Hart <http://github.com/hartbit/>
Review Manager: TBD
Status: TBD
<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#introduction>Introduction

The proposal introduces a new swift run command to build and run an executable defined in the current package.

<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#motivation>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.

<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#proposed-solution>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 <https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/0146-package-manager-product-definitions.md>. 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.

<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#alternatives-considered>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.


(Rien) #2

I always wondered why it did not exist already :wink:

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@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


(Robert Widmann) #3

+1. A very useful feature to have, indeed.

~Robert Widmann

···

On May 15, 2017, at 1:47 AM, 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 <https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md>
Authors: David Hart <http://github.com/hartbit/>
Review Manager: TBD
Status: TBD
<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#introduction>Introduction

The proposal introduces a new swift run command to build and run an executable defined in the current package.

<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#motivation>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.

<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#proposed-solution>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 <https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/0146-package-manager-product-definitions.md>. 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.

<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#alternatives-considered>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


(Ankit Aggarwal) #4

Hi,

Thanks a lot for working on this. I am in favour of the proposal. We can
nitpick on the name (swift run, swift package run, swift execute) but
otherwise this looks like a reasonable feature to add.

···

On Mon, May 15, 2017 at 1:17 PM, David Hart via swift-build-dev < swift-build-dev@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
   <https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md>
   - Authors: David Hart <http://github.com/hartbit/>
   - Review Manager: TBD
   - Status: TBD

<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#introduction>
Introduction

The proposal introduces a new swift run command to build and run an
executable defined in the current package.

<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#motivation>
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.

<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#proposed-solution>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
<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/0146-package-manager-product-definitions.md>.
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.

<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#alternatives-considered>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-build-dev mailing list
swift-build-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev


(David Hart) #5

I always wondered why it did not exist already :wink:

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.

···

On 15 May 2017, at 10:03, Rien <Rien@balancingrock.nl> wrote:

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


(Daniel Dunbar) #6

Huge +1 from me, and for having it build by default. Building should be
efficient & transparent to the user IMHO.

···

On Mon, May 15, 2017 at 11:43 AM Robert Widmann via swift-build-dev < swift-build-dev@swift.org> wrote:

+1. A very useful feature to have, indeed.

~Robert Widmann

On May 15, 2017, at 1:47 AM, 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
   <https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md>
   - Authors: David Hart <http://github.com/hartbit/>
   - Review Manager: TBD
   - Status: TBD

<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#introduction>
Introduction

The proposal introduces a new swift run command to build and run an
executable defined in the current package.

<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#motivation>
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.

<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#proposed-solution>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
<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/0146-package-manager-product-definitions.md>.
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.

<https://github.com/hartbit/swift-evolution/blob/swift-run-command/proposals/XXXX-swift-run-command.md#alternatives-considered>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-build-dev mailing list
swift-build-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev


(Rien) #7

I always wondered why it did not exist already :wink:

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.

···

On 15 May 2017, at 10:12, David Hart <david@hartbit.com> wrote:

On 15 May 2017, at 10:03, Rien <Rien@balancingrock.nl> wrote:

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


(David Sweeris) #8

Agreed.

- Dave Sweeris

···

On May 15, 2017, at 11:49 AM, Daniel Dunbar via swift-build-dev <swift-build-dev@swift.org> wrote:

Huge +1 from me, and for having it build by default. Building should be efficient & transparent to the user IMHO.


(Tony Allevato) #9

+1; this would be a big improvement for a number of my smaller projects.

Building-before-running should absolutely be the implemented behavior. Off
the top of my head, two build systems I'm familiar with—Buck and Bazel—both
do a build as part of their "run" command. Likewise, having a "run" command
that doesn't build makes it effectively useless—having to build explicitly
first makes the "run" command not much better than just running the
executable in the .build folder directly.

···

On Mon, May 15, 2017 at 11:56 AM David Sweeris via swift-evolution < swift-evolution@swift.org> wrote:

> On May 15, 2017, at 11:49 AM, Daniel Dunbar via swift-build-dev < > swift-build-dev@swift.org> wrote:
>
> Huge +1 from me, and for having it build by default. Building should be
efficient & transparent to the user IMHO.

Agreed.

- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Hart) #10

I always wondered why it did not exist already :wink:

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?

David.

···

On 15 May 2017, at 10:40, Rien <Rien@balancingrock.nl> wrote:

On 15 May 2017, at 10:12, David Hart <david@hartbit.com> wrote:

On 15 May 2017, at 10:03, Rien <Rien@balancingrock.nl> wrote:

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


(Rien) #11

I always wondered why it did not exist already :wink:

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 :wink:
On the command line I like single-purpose commands since that makes creating and understanding scripts easier.
Maybe that is just me…

Rien.

···

On 15 May 2017, at 11:58, David Hart <david@hartbit.com> wrote:

On 15 May 2017, at 10:40, Rien <Rien@balancingrock.nl> wrote:

On 15 May 2017, at 10:12, David Hart <david@hartbit.com> wrote:

On 15 May 2017, at 10:03, Rien <Rien@balancingrock.nl> wrote:

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


(Xiaodi Wu) #12

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 <david@hartbit.com> wrote:
>
>>
>> On 15 May 2017, at 10:40, Rien <Rien@balancingrock.nl> wrote:
>>
>>
>>> On 15 May 2017, at 10:12, David Hart <david@hartbit.com> wrote:
>>>
>>>
>>>> On 15 May 2017, at 10:03, Rien <Rien@balancingrock.nl> wrote:
>>>>
>>>> I always wondered why it did not exist already :wink:
>>>>
>>>> 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 :wink:
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