Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

[David Sweeris via swift-evolution]

> On Mar 29, 2017, at 10:56, Ankit Aggarwal  wrote:
> 
> We discussed variadic overloads during the manifest redesign proposal but 
> ultimately rejected it. We could add an overload for a singular source file 
> (instead of variadic) but I think its simpler to just have one option, and it 
> is also easier when you want to extend your source list form one to two.

K, seems reasonable.

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

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

[Ankit Aggarwal via swift-evolution]

We discussed variadic overloads during the manifest redesign proposal but 
ultimately rejected 

 it. We could add an overload for a singular source file (instead of variadic) 
but I think its simpler to just have one option, and it is also easier when you 
want to extend your source list form one to two.

I think parsing is not a concern because tools are expected to ask for JSON 
representation and not directly parse the swift file.


> On 29-Mar-2017, at 11:18 PM, David Sweeris  wrote:
> 
> 
> On Mar 29, 2017, at 10:19, Ankit Aggarwal via swift-build-dev 
> > wrote:
> 
>> The proposal 
>> 
>>  is updated with this change.
> 
> What do we think about adding convenience inits that take a single parameter 
> in place of the []s, for when we're only passing one value?
> 
> The down side is that it makes it more complicated for 3rd party tools to 
> parse. Dunno if that's a concern.
> 
> - Dave Sweeris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

[David Sweeris via swift-evolution]

On Mar 29, 2017, at 10:19, Ankit Aggarwal via swift-build-dev 
 wrote:

> The proposal is updated with this change.

What do we think about adding convenience inits that take a single parameter in 
place of the []s, for when we're only passing one value?

The down side is that it makes it more complicated for 3rd party tools to 
parse. Dunno if that's a concern.

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

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

[Ankit Aggarwal via swift-evolution]

Oops, I had pressed reply instead reply all. The proposal

is
updated with this change.

On Mon, Mar 27, 2017 at 12:32 PM, Ankit Aggarwal 
wrote:

> Hi Brent,
>
> I agree, this sounds like a reasonable thing to do. We can probably emit a
> warning when its set to an empty array.
>
> Thanks!
>
> On Mon, Mar 27, 2017 at 10:57 AM, Brent Royal-Gordon via swift-build-dev <
> swift-build-...@swift.org> wrote:
>
>> On Mar 24, 2017, at 1:26 PM, Ankit Aggarwal via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> sources: This property defines the source files to be included in the
>> target, relative to the target path. The default value of this property
>> will be an empty array, which means all valid source files found in the
>> target's path will be included.
>>
>>
>> Stupid little niggle: could this be an optional array with a default
>> value of `nil`? It seems more natural to treat the absence of a `sources`
>> list as meaning "auto-detect" than to treat an empty `sources` list that
>> way.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>>
>> ___
>> swift-build-dev mailing list
>> swift-build-...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-build-dev
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

[Jens Nerup via swift-evolution]

+1

> On 27 Mar 2017, at 07.27, Brent Royal-Gordon via swift-build-dev 
>  wrote:
> 
>> On Mar 24, 2017, at 1:26 PM, Ankit Aggarwal via swift-evolution 
>> > wrote:
>> 
>> sources: This property defines the source files to be included in the 
>> target, relative to the target path. The default value of this property will 
>> be an empty array, which means all valid source files found in the target's 
>> path will be included.
> 
> 
> Stupid little niggle: could this be an optional array with a default value of 
> `nil`? It seems more natural to treat the absence of a `sources` list as 
> meaning "auto-detect" than to treat an empty `sources` list that way.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-build-dev mailing list
> swift-build-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

[David Sweeris via swift-evolution]

Agreed

Sent from my iPhone

> On Mar 26, 2017, at 22:27, Brent Royal-Gordon via swift-build-dev 
>  wrote:
> 
>> On Mar 24, 2017, at 1:26 PM, Ankit Aggarwal via swift-evolution 
>>  wrote:
>> 
>> sources: This property defines the source files to be included in the 
>> target, relative to the target path. The default value of this property will 
>> be an empty array, which means all valid source files found in the target's 
>> path will be included.
> 
> 
> Stupid little niggle: could this be an optional array with a default value of 
> `nil`? It seems more natural to treat the absence of a `sources` list as 
> meaning "auto-detect" than to treat an empty `sources` list that way.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-build-dev mailing list
> swift-build-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

[Ankit Aggarwal via swift-evolution]

Hi Joesph,

Thank you for the feedback!


> For the C target classes, I'd like to also see linker flags defined for
> those packages, as currently that has to be included in additional flags
> and maintained entirely outside the package structure with scripting,
> Makefiles, or the like. That may be quite a bit beyond the current proposal
> of making the directories explicit rather than based on convention, but
> since this addresses the C target header search paths as well, it seems
> relevant.
>

We do need to add support for that but linker flags falls under build
settings and not this proposal. This proposal allows customising the path
to the directory containing public headers which is currently hard coded to
"include".
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

[Ankit Aggarwal via swift-evolution]

Hi Karl,

Thank you for the feedback, comments inline.


> 1) I’m not sure about listing all of the test targets together with the
> product targets. I feel it may be better to have them as separate Arrays.
>

They both are similar entity so they stay together. Another example is
products, which can be an executable or a library. It is also easier to
scale if these are not separate. Otherwise, we need to keep adding new
properties to the top level Package structure every time we introduce a new
type of target.


2) I think we need a way to specify directories non-recursively. For
> example:
>
> - Sources
> | - Foo
> | | - MultipleImplementations
> | | | - Impl1
> | | | - Impl2
>
> In this case, “MultipleImplementations” contains some common definitions,
> but has multiple potential implementations. Impl1 and Impl2 will each
> implement the functionality in their own way, perhaps making use of
> platform-specific features or optional dependencies. Basically, I want to
> import “MultipleImplementations” non-recursively, then decide which
> subdirectory/implementation to use based on some build condition:
>
> .Target(“Foo”, sources: [“Sources/Foo”, “[NR]Sources/Foo/
> MultipleImplementations”])
>
> if someCondition {
>   package.targets[0].sources.append(“Sources/Foo/
> MultipleImplementations/Impl1”)
> else {
>   package.targets[0].sources.append(“Sources/Foo/
> MultipleImplementations/Impl2”)
> }
>
> The workaround today is to test for the inverse and add every other
> directory to “exclude”, but that’s not an elegant long-term solution.
>

We agree we need to support more complex specifications. We plan to add
support for globbing and conditionals in future (there is a note about that
in the proposal). Both of these are additive features and this proposals
gives us a good base for designing that.

Thanks,
Ankit
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

[Joseph Heck via swift-evolution]

I like the explicitness and flexibility that providing these inputs via 
declaration in the package manager format. 

For the C target classes, I'd like to also see linker flags defined for those 
packages, as currently that has to be included in additional flags and 
maintained entirely outside the package structure with scripting, Makefiles, or 
the like. That may be quite a bit beyond the current proposal of making the 
directories explicit rather than based on convention, but since this addresses 
the C target header search paths as well, it seems relevant.

 - joe

> On Mar 24, 2017, at 1:26 PM, Ankit Aggarwal via swift-build-dev 
>  wrote:
> 
> Hi,
> 
> We would love to get some feedback on a draft proposal for defining custom 
> target layouts in the Package Manager. This proposal allows overriding the 
> target layout rules set by the Package Manager and simplifies some complex 
> "magic" behaviours. 
> 
> You can find the proposal at the link below. The text is also included in the 
> email.
> 
> https://github.com/aciidb0mb3r/swift-evolution/blob/custom-targets-layout/proposals/-package-manager-custom-targets-layout.md
> 
> Thanks,
> Ankit
> 
> --
> 
> Package Manager Custom Targets Layout
> Proposal: SE-
> Author: Ankit Aggarwal
> Review Manager: TBD
> Status: Discussion
> Bug: SR-29
> Introduction
> This proposal enhances the Package.swift manifest APIs to support custom 
> target layouts, and removes a convention which allowed omission of targets 
> from the manifest.
> 
> Motivation
> The Package Manager uses a convention system to infer targets structure from 
> disk layout. This works well for most packages, which can easily adopt the 
> conventions, and frees users from needing to update their Package.swift file 
> every time they add or remove sources. Adopting the conventions is more 
> difficult for some packages, however – especially existing C libraries or 
> large projects, which would be difficult to reorganize. We intend to give 
> users a way to make such projects into packages without needing to conform to 
> our conventions.
> 
> The current convention rules make it very convenient to add new targets and 
> source files by inferring them automatically from disk, but they also can be 
> confusing, overly-implicit, and difficult to debug; for example, if the user 
> does not follow the conventions correctly which determine their targets, they 
> may wind up with targets they don't expect, or not having targets they did 
> expect, and either way their clients can't easily see which targets are 
> available by looking at the Package.swift manifest. We want to retain 
> convenience where it really matters, such as easy addition of new source 
> files, but require explicit declarations where being explicit adds 
> significant value. We also want to make sure that the implicit conventions we 
> keep are straightforward and easy to remember.
> 
> Proposed solution
> We propose to stop inferring targets from disk. They must be explicitly 
> declared in the manifest file. The inference was not very useful, as targets 
> eventually need to be declared in order to use common features such as 
> product and target dependencies, or build settings (which are planned for 
> Swift 4). Explicit target declarations make a package easier to understand by 
> clients, and allow us to provide good diagnostics when the layout on disk 
> does not match the declarations.
> 
> We propose to remove the requirement that name of a test target must have 
> suffix "Tests". Instead, test targets will be explicitly declared as such in 
> the manifest file.
> 
> We propose a list of pre-defined search paths for declared targets.
> 
> When a target does not declare an explicit path, these directories will be 
> used to search for the target. The name of the directory must match the name 
> of the target. The search will be done in order and will be case-sensitive.
> 
> Regular targets: package root, Sources, Source, src, srcs. Test targets: 
> Tests, package root, Sources, Source, src, srcs.
> 
> It is an error if a target is found in more than one of these paths. In such 
> cases, the path should be explicitly declared using the path property 
> proposed below.
> 
> We propose to add a factory method testTarget to the Target class, to define 
> test targets.
> 
> .testTarget(name: "FooTests", dependencies: ["Foo"])
> We propose to add three properties to the Target class: path, sources 
> andexclude.
> 
> path: This property defines the path to the top-level directory containing 
> the target's sources, relative to the package root. It is not legal for this 
> path to escape the package root, i.e., values like "../Foo", "/Foo" are 
> invalid. The default value of this property will be nil, which means the 
> target will be searched for in the pre-defined paths. The empty string ("") 
> or dot (".") implies that the target's sources are directly inside the 
> package root.
> 
>