[swift-build-dev] Build and run arbitrary targets

[Ankit Aggarwal]

--
Ankit

> On 05-Jul-2017, at 2:54 PM, David Hart <davidhart at fastmail.com> wrote:
> 
> 
>> On 5 Jul 2017, at 11:22, Ankit Aggarwal <ankit_aggarwal at apple.com <mailto:ankit_aggarwal at apple.com>> wrote:
>> 
>> 
>> 
>> --
>> Ankit
>> 
>>> On 05-Jul-2017, at 2:37 PM, David Hart <davidhart at fastmail.com <mailto:davidhart at fastmail.com>> wrote:
>>> 
>>> 
>>>> On 5 Jul 2017, at 10:49, Ankit Aggarwal <ankit_aggarwal at apple.com <mailto:ankit_aggarwal at apple.com>> wrote:
>>>> 
>>>> I think all these options make sense. Some comments inline.
>>>> 
>>>>> On 05-Jul-2017, at 2:18 AM, David Hart <david at hartbit.com <mailto:david at 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 <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 :)
>>> 
>>>>> 
>>>>> 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”?

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20170705/875e5125/attachment.html>