+ swift-build-dev
To take a step back here, there are two problems I see in this space:
1) Building unnecessary test-only stuff.
Say you have a package A which depends on a package B. B might declare a
library, a test module, and some auxiliary target that's only needed by the
tests. Today, if you check out A and run `swift build`, it will build B's
auxiliary target (among other things built). That's unnecessary, and it would
be nice to avoid that.
The product definitions proposal will fix this. Once that's implemented, B
would publish its library as its only product, and A would declare that it
depends on that product. Then, when building A, we would know that we don't
need the auxiliary target from B, and wouldn't build it. So I think the
products proposal will solve this problem.
2) Cloning unnecessary test-only stuff.
Say you have a package A which depends on a package B, and B has a test module
which depends on a package C. Once the products proposal has been implemented
and you adopt it, running `swift build` on A will be smart enough not to build
the test module from B or any of the targets from C; however, SwiftPM will
still clone the C repository when doing dependency resolution, even though it
never winds up building its products.
I don't personally see that as a major problem, but it is one that would be
nice to address at some point. Ways we could address this include:
– We could add a "testDependencies" property on the package. These dependencies
would only be resolved and cloned in situations where one or more test targets
from that package need to be built. Some problems with this would be:
* Since these dependencies would only conditionally resolve, but
otherwise would affect dependency resolution as normal, this could lead to some
really unexpected emergent behavior. For example, if a package that's only
included in the graph via testDependencies happens to depend on another package
that's otherwise already in the graph, but with a more restrictive version
specification, then whether or not you're building tests would force that other
package to re-resolve with a different version.
* This is a non-generalized solution to a general problem. That is,
once we have the products proposal implemented, you could wind up in this
situation with no tests involved, but this mechanism wouldn't solve the problem
in that case. To give a concrete example, if A depends on B, B vends two
products, and only one of them depends on C, it's unnecessary to clone C unless
the product that needs it is used by A. A properly general mechanism would let
you make that dependency conditional on whether you need it for whatever
reason, and not tie it to testing in particular. Another reason you might have
this problem is if you have a dependency that only applies on one platform
(e.g. linux but not macOS). (Conditional compilation blocks can be used for the
platform case, but – once we have a better mechanism – I don't think that they
should be used, for reasons that would be best discussed in its own thread).
* Adding additional properties to the Package should be done carefully.
Every new property is new API surface area, and makes our documentation,
initializer, etc more complicated. In my opinion, this new property doesn't
justify that cost if it's just saving you from initial cloning of the extra
packages.
– We could add in-line dependencies for targets, as Ankit suggested. This is a
more generalizable mechanism than "testDependencies". That said, it could
potentially require you to duplicate your dependency declaration, which is bad.
(E.g. if two test targets in your package depend on the same auxiliary package,
that dependency would need to be stated twice). It also adds unfortunate
complexity.
– We could add a general mechanism for declaring dependencies as conditional,
supporting a variety of possible conditions. Some of the SwiftPM developers are
in the early discussion stages for a proposal for how to to make various parts
of a manifest conditional, as part of a larger conversation on build settings;
we'll bring our thoughts to this list once we have something coherent to
propose. But if we come up with a general syntax for making things like
settings conditional, the same consistent syntax could potentially be applied
to dependencies as well.
- - -
Personally, I think that the products proposal solves the first problem nicely,
and that we should revisit the second problem as part of an upcoming
conversation about conditionals in the manifest.
- Rick
> On Jan 30, 2017, at 11:55 AM, Robert Widmann via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On Jan 30, 2017, at 2:38 PM, Ankit Agarwal <an...@ankit.im
>> <mailto:an...@ankit.im>> wrote:
>>
>>
>> Not in practice (with respect to package manifests). In fact, it seems that,
>> given there are separate commands (swift build and swift test), separate
>> directories (Sources and Tests), and separate products, that there's a hole
>> to be filled here by separate handling for test suites in package manifests.
>>
>> FWIW, overriding conventions will potentially allow you control the layout
>> of the package (when we have that feature).
>
> In that case, as long as there are plans for this kind of feature, I can hold
> off on submitting this proposal until it materializes.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
