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

[Ankit Aggarwal]

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 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
>    <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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20170515/0ca1aa39/attachment.html>