Build and run arbitrary targets


(David Hart) #1

Hello mailing-list,

I’m planning on adding options to the swift build command to allow building specific targets or products in the package and its dependencies. And allow swift run to execute arbitrary products in all the package’s dependencies. I’d like to get feedback on those before going forward or not.

Motivation

The swift build command builds all the package targets but doesn’t allow building a specific target or a dependency’s product. This can be useful during development when concentrating on a single target.

The swift run command searches for an executable to run in the package dependency graph but won’t find it unless it is declared as a target dependency, which is rarely the case. For example, a package using the code generation capabilities of the executable product in the Sourcery <https://github.com/krzysztofzablocki/Sourcery> package can’t run it with swift run sourcery unless the executable is added as a product dependency, linking the executable's module, which doesn't make much sense.

Build

To solve both issues above, I was planning on adding 3 new options to the swift build tool:

  --target Specify target to build
  --product Specify product to build from the package or its dependencies
  --package Specify the package to build

Here are different examples using those options:

# Builds the Basic target from the root package.
$ swift build —target Basic

# Searches for a product named SwiftyJSON in the root package and its dependencies and builds it.
$ swift build —product SwiftyJSON

# Builds all products of the Sourcery package dependency.
$ swift build —package Sourcery

# Builds the sourcery product from the Sourcery package.
$ swift build —package Sourcery —product sourcery

To mirror the behavior of products in the package definition format in SE-0146 <https://github.com/apple/swift-evolution/blob/master/proposals/0146-package-manager-product-definitions.md>:
The --target option can not reference targets in dependent packages because they are considered as implementation details.
The --product option is generally enough to unambiguously reference a product because product names are expected to be unique. If it is not the case, the --package option is available for disambiguation.
Run

To allow the swift run command to reference products which are not depended on, the swift build --package option will also support referencing products which are not depended on. Indeed, as the run command implicitly runs the build command, it makes more sense to give both commands to same features.

Thanks in advance for your feedback,

Regards,
David.


(Ankit Aggarwal) #3

I think all these options make sense. Some comments inline.

Hello mailing-list,

I’m planning on adding options to the swift build command to allow building specific targets or products in the package and its dependencies. And allow swift run to execute arbitrary products in all the package’s dependencies. I’d like to get feedback on those before going forward or not.

Motivation

The swift build command builds all the package targets but doesn’t allow building a specific target or a dependency’s product. This can be useful during development when concentrating on a single target.

The swift run command searches for an executable to run in the package dependency graph but won’t find it unless it is declared as a target dependency, which is rarely the case. For example, a package using the code generation capabilities of the executable product in the Sourcery <https://github.com/krzysztofzablocki/Sourcery> package can’t run it with swift run sourcery unless the executable is added as a product dependency, linking the executable's module, which doesn't make much sense.

Build

To solve both issues above, I was planning on adding 3 new options to the swift build tool:

  --target Specify target to build
  --product Specify product to build from the package or its dependencies
  --package Specify the package to build

Here are different examples using those options:

# Builds the Basic target from the root package.
$ swift build —target Basic

# Searches for a product named SwiftyJSON in the root package and its dependencies and builds it.
$ swift build —product SwiftyJSON

# Builds all products of the Sourcery package dependency.
$ swift build —package Sourcery

# Builds the sourcery product from the Sourcery package.
$ swift build —package Sourcery —product sourcery

These are supposed to be two dashes (--), right?

To mirror the behavior of products in the package definition format in SE-0146 <https://github.com/apple/swift-evolution/blob/master/proposals/0146-package-manager-product-definitions.md>:
The --target option can not reference targets in dependent packages because they are considered as implementation details.

I think it should be allowed to search the entire package graph for the target and not just top level dependencies. The target names are supposed to be unique anyway.

···

On 05-Jul-2017, at 2:18 AM, David Hart <david@hartbit.com> wrote:

The --product option is generally enough to unambiguously reference a product because product names are expected to be unique. If it is not the case, the --package option is available for disambiguation.
Run

To allow the swift run command to reference products which are not depended on, the swift build --package option will also support referencing products which are not depended on. Indeed, as the run command implicitly runs the build command, it makes more sense to give both commands to same features.

Thanks in advance for your feedback,

Regards,
David.

--
Ankit


(David Hart) #4

I think all these options make sense. Some comments inline.

Hello mailing-list,

I’m planning on adding options to the swift build command to allow building specific targets or products in the package and its dependencies. And allow swift run to execute arbitrary products in all the package’s dependencies. I’d like to get feedback on those before going forward or not.

Motivation

The swift build command builds all the package targets but doesn’t allow building a specific target or a dependency’s product. This can be useful during development when concentrating on a single target.

The swift run command searches for an executable to run in the package dependency graph but won’t find it unless it is declared as a target dependency, which is rarely the case. For example, a package using the code generation capabilities of the executable product in the Sourcery <https://github.com/krzysztofzablocki/Sourcery> package can’t run it with swift run sourcery unless the executable is added as a product dependency, linking the executable's module, which doesn't make much sense.

Build

To solve both issues above, I was planning on adding 3 new options to the swift build tool:

  --target Specify target to build
  --product Specify product to build from the package or its dependencies
  --package Specify the package to build

Here are different examples using those options:

# Builds the Basic target from the root package.
$ swift build —target Basic

# Searches for a product named SwiftyJSON in the root package and its dependencies and builds it.
$ swift build —product SwiftyJSON

# Builds all products of the Sourcery package dependency.
$ swift build —package Sourcery

# Builds the sourcery product from the Sourcery package.
$ swift build —package Sourcery —product sourcery

These are supposed to be two dashes (--), right?

Yes, sorry :slight_smile:

To mirror the behavior of products in the package definition format in SE-0146 <https://github.com/apple/swift-evolution/blob/master/proposals/0146-package-manager-product-definitions.md>:
The --target option can not reference targets in dependent packages because they are considered as implementation details.

I think it should be allowed to search the entire package graph for the target and not just top level dependencies. The target names are supposed to be unique anyway.

My idea was to limit it to the project’s package (not even on the first-level dependencies) not for a question of uniqueness but to mirror the fact that SE-0146 removed the possibility to depend on other packages targets specifically because they are supposed to be private implementation details (which is great IMHO):

For example, consider the package for a component that has both a library API and command line tools. Such a package is also likely to be partitioned into a set of core libraries on which both the public library and the command line tools depend, but which should remain a private implementation detail as far as clients are concerned.

If we permitted swift build —target PrivateTargetInOtherPackage to build those private implementation details, wouldn’t we put tools which use this functionality in a brittle situation?

···

On 5 Jul 2017, at 10:49, Ankit Aggarwal <ankit_aggarwal@apple.com> wrote:

On 05-Jul-2017, at 2:18 AM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> wrote:
The --product option is generally enough to unambiguously reference a product because product names are expected to be unique. If it is not the case, the --package option is available for disambiguation.
Run

To allow the swift run command to reference products which are not depended on, the swift build --package option will also support referencing products which are not depended on. Indeed, as the run command implicitly runs the build command, it makes more sense to give both commands to same features.

Thanks in advance for your feedback,

Regards,
David.

--
Ankit


(Ankit Aggarwal) #5
···


Ankit

On 05-Jul-2017, at 2:37 PM, David Hart davidhart@fastmail.com wrote:

On 5 Jul 2017, at 10:49, Ankit Aggarwal ankit_aggarwal@apple.com wrote:

I think all these options make sense. Some comments inline.

On 05-Jul-2017, at 2:18 AM, David Hart david@hartbit.com wrote:

Hello mailing-list,

I’m planning on adding options to the swift build command to allow building specific targets or products in the package and its dependencies. And allow swift run to execute arbitrary products in all the package’s dependencies. I’d like to get feedback on those before going forward or not.

Motivation

The swift build command builds all the package targets but doesn’t allow building a specific target or a dependency’s product. This can be useful during development when concentrating on a single target.

The swift run command searches for an executable to run in the package dependency graph but won’t find it unless it is declared as a target dependency, which is rarely the case. For example, a package using the code generation capabilities of the executable product in the Sourcery package can’t run it with swift run sourcery unless the executable is added as a product dependency, linking the executable’s module, which doesn’t make much sense.

Build

To solve both issues above, I was planning on adding 3 new options to the swift build tool:

–target Specify target to build
–product Specify product to build from the package or its dependencies
–package Specify the package to build

Here are different examples using those options:

Builds the Basic target from the root package.

$ swift build —target Basic

Searches for a product named SwiftyJSON in the root package and its dependencies and builds it.

$ swift build —product SwiftyJSON

Builds all products of the Sourcery package dependency.

$ swift build —package Sourcery

Builds the sourcery product from the Sourcery package.

$ swift build —package Sourcery —product sourcery

These are supposed to be two dashes (–), right?

Yes, sorry :slight_smile:

To mirror the behavior of products in the package definition format in SE-0146:

  • The –target option can not reference targets in dependent packages because they are considered as implementation details.

I think it should be allowed to search the entire package graph for the target and not just top level dependencies. The target names are supposed to be unique anyway.

My idea was to limit it to the project’s package (not even on the first-level dependencies) not for a question of uniqueness but to mirror the fact that SE-0146 removed the possibility to depend on other packages targets specifically because they are supposed to be private implementation details (which is great IMHO):

For example, consider the package for a component that has both a library API and command line tools. Such a package is also likely to be partitioned into a set of core libraries on which both the public library and the command line tools depend, but which should remain a private implementation detail as far as clients are concerned.

If we permitted swift build —target PrivateTargetInOtherPackage to build those private implementation details, wouldn’t we put tools which use this functionality in a brittle situation?

I think SE-0146 is a little different in the way that the manifest file is involved. The manifest file can become invalid if it depends on some private target and that target is removed on a package update. The CLI tool will be used by the end user and doesn’t need a lot of “protection”.

  • The –product option is generally enough to unambiguously reference a product because product names are expected to be unique. If it is not the case, the –package option is available for disambiguation.
    Run

To allow the swift run command to reference products which are not depended on, the swift build --package option will also support referencing products which are not depended on. Indeed, as the run command implicitly runs the build command, it makes more sense to give both commands to same features.

Thanks in advance for your feedback,

Regards,

David.


Ankit


(David Hart) #6

--
Ankit

I think all these options make sense. Some comments inline.

Hello mailing-list,

I’m planning on adding options to the swift build command to allow building specific targets or products in the package and its dependencies. And allow swift run to execute arbitrary products in all the package’s dependencies. I’d like to get feedback on those before going forward or not.

Motivation

The swift build command builds all the package targets but doesn’t allow building a specific target or a dependency’s product. This can be useful during development when concentrating on a single target.

The swift run command searches for an executable to run in the package dependency graph but won’t find it unless it is declared as a target dependency, which is rarely the case. For example, a package using the code generation capabilities of the executable product in the Sourcery <https://github.com/krzysztofzablocki/Sourcery> package can’t run it with swift run sourcery unless the executable is added as a product dependency, linking the executable's module, which doesn't make much sense.

Build

To solve both issues above, I was planning on adding 3 new options to the swift build tool:

  --target Specify target to build
  --product Specify product to build from the package or its dependencies
  --package Specify the package to build

Here are different examples using those options:

# Builds the Basic target from the root package.
$ swift build —target Basic

# Searches for a product named SwiftyJSON in the root package and its dependencies and builds it.
$ swift build —product SwiftyJSON

# Builds all products of the Sourcery package dependency.
$ swift build —package Sourcery

# Builds the sourcery product from the Sourcery package.
$ swift build —package Sourcery —product sourcery

These are supposed to be two dashes (--), right?

Yes, sorry :slight_smile:

To mirror the behavior of products in the package definition format in SE-0146 <https://github.com/apple/swift-evolution/blob/master/proposals/0146-package-manager-product-definitions.md>:
The --target option can not reference targets in dependent packages because they are considered as implementation details.

I think it should be allowed to search the entire package graph for the target and not just top level dependencies. The target names are supposed to be unique anyway.

My idea was to limit it to the project’s package (not even on the first-level dependencies) not for a question of uniqueness but to mirror the fact that SE-0146 removed the possibility to depend on other packages targets specifically because they are supposed to be private implementation details (which is great IMHO):

For example, consider the package for a component that has both a library API and command line tools. Such a package is also likely to be partitioned into a set of core libraries on which both the public library and the command line tools depend, but which should remain a private implementation detail as far as clients are concerned.

If we permitted swift build —target PrivateTargetInOtherPackage to build those private implementation details, wouldn’t we put tools which use this functionality in a brittle situation?

I think SE-0146 is a little different in the way that the manifest file is involved. The manifest file can become invalid if it depends on some private target and that target is removed on a package update. The CLI tool will be used by the end user and doesn't need a lot of "protection”.

Aren’t you worried that the CLI tool will not necessarily be used by the end user but also be used by third-party tools which require that “protection”?

···

On 5 Jul 2017, at 11:22, Ankit Aggarwal <ankit_aggarwal@apple.com> wrote:

On 05-Jul-2017, at 2:37 PM, David Hart <davidhart@fastmail.com <mailto:davidhart@fastmail.com>> wrote:

On 5 Jul 2017, at 10:49, Ankit Aggarwal <ankit_aggarwal@apple.com <mailto:ankit_aggarwal@apple.com>> wrote:

On 05-Jul-2017, at 2:18 AM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> wrote:
The --product option is generally enough to unambiguously reference a product because product names are expected to be unique. If it is not the case, the --package option is available for disambiguation.
Run

To allow the swift run command to reference products which are not depended on, the swift build --package option will also support referencing products which are not depended on. Indeed, as the run command implicitly runs the build command, it makes more sense to give both commands to same features.

Thanks in advance for your feedback,

Regards,
David.

--
Ankit


(Ankit Aggarwal) #7
···


Ankit

On 05-Jul-2017, at 2:54 PM, David Hart davidhart@fastmail.com wrote:

On 5 Jul 2017, at 11:22, Ankit Aggarwal ankit_aggarwal@apple.com wrote:


Ankit

On 05-Jul-2017, at 2:37 PM, David Hart davidhart@fastmail.com wrote:

On 5 Jul 2017, at 10:49, Ankit Aggarwal ankit_aggarwal@apple.com wrote:

I think all these options make sense. Some comments inline.

On 05-Jul-2017, at 2:18 AM, David Hart david@hartbit.com wrote:

Hello mailing-list,

I’m planning on adding options to the swift build command to allow building specific targets or products in the package and its dependencies. And allow swift run to execute arbitrary products in all the package’s dependencies. I’d like to get feedback on those before going forward or not.

Motivation

The swift build command builds all the package targets but doesn’t allow building a specific target or a dependency’s product. This can be useful during development when concentrating on a single target.

The swift run command searches for an executable to run in the package dependency graph but won’t find it unless it is declared as a target dependency, which is rarely the case. For example, a package using the code generation capabilities of the executable product in the Sourcery package can’t run it with swift run sourcery unless the executable is added as a product dependency, linking the executable’s module, which doesn’t make much sense.

Build

To solve both issues above, I was planning on adding 3 new options to the swift build tool:

–target Specify target to build
–product Specify product to build from the package or its dependencies
–package Specify the package to build

Here are different examples using those options:

Builds the Basic target from the root package.

$ swift build —target Basic

Searches for a product named SwiftyJSON in the root package and its dependencies and builds it.

$ swift build —product SwiftyJSON

Builds all products of the Sourcery package dependency.

$ swift build —package Sourcery

Builds the sourcery product from the Sourcery package.

$ swift build —package Sourcery —product sourcery

These are supposed to be two dashes (–), right?

Yes, sorry :slight_smile:

To mirror the behavior of products in the package definition format in SE-0146:

  • The –target option can not reference targets in dependent packages because they are considered as implementation details.

I think it should be allowed to search the entire package graph for the target and not just top level dependencies. The target names are supposed to be unique anyway.

My idea was to limit it to the project’s package (not even on the first-level dependencies) not for a question of uniqueness but to mirror the fact that SE-0146 removed the possibility to depend on other packages targets specifically because they are supposed to be private implementation details (which is great IMHO):

For example, consider the package for a component that has both a library API and command line tools. Such a package is also likely to be partitioned into a set of core libraries on which both the public library and the command line tools depend, but which should remain a private implementation detail as far as clients are concerned.

If we permitted swift build —target PrivateTargetInOtherPackage to build those private implementation details, wouldn’t we put tools which use this functionality in a brittle situation?

I think SE-0146 is a little different in the way that the manifest file is involved. The manifest file can become invalid if it depends on some private target and that target is removed on a package update. The CLI tool will be used by the end user and doesn’t need a lot of "protection”.

Aren’t you worried that the CLI tool will not necessarily be used by the end user but also be used by third-party tools which require that “protection”?

It is difficult to predict the requirements of a third party tool. They can build their own protection if they need it (for e.g. by querying for root targets/dependencies etc). IMO, it will be limiting to not allow this.

  • The –product option is generally enough to unambiguously reference a product because product names are expected to be unique. If it is not the case, the –package option is available for disambiguation.
    Run

To allow the swift run command to reference products which are not depended on, the swift build --package option will also support referencing products which are not depended on. Indeed, as the run command implicitly runs the build command, it makes more sense to give both commands to same features.

Thanks in advance for your feedback,

Regards,

David.


Ankit