Allow any "Tests"-suffixed directories to be ignored from swift build.

[inamiy]

According to Documentation/SourceLayouts.md, only directory named "Tests" can be ignored from swift build, but Xcode normally generates directory name e.g. MyFrameworkTests, and I want to ignore this as well.

BTW, it will be even better if we can specify test directory names in Package.swift 😊

[natestedman]

In general, the ability to filter arbitrary directories would be useful - for example, the package manager currently considers a Carthage directory to be a package, and attempts to build it. This goes... poorly.

Unless this is intentional, and the desired practice is to put files in Sources if you have .swift files anywhere else that you don't want built. That's reasonable, "one and only one obvious way", etc.

[mxcl]

BTW, it will be even better if we can specify test directory names in Package.swift

The ability to exclude is planned.

Probably this is a correct route however, but I'd like to stew on it and involve @ddunbar in the discussion.

[emish]

I think it would be interesting for the "Tests" directory to be the canonical location for test targets and source files.

[mattt]

I agree with @emish, that specifying Tests as the canonical location for all tests for a package is a good convention to have. It's simple, easy to explain, and creates symmetry with the Sources directory convention. Multiple groups of tests of additional subdivisions should be something handled by configuration in the manifest.

The logic for checking for the existence of a suffix gets complicated quickly, as it would need to accept or reject different cases ("Tests" / "tests" / "TESTS") in a way that is consistent with substrings ("Contests" vs. "ConTests" vs. "CONTests"... which ones create a module, and which ones become tests?). Rather than go to the trouble of worrying about all of the possible ways this could break, it's much better for both the developer and the end user to set a simple default convention and provide a way to configure around it.

[mxcl]

In the interest of backwards compatibility with how Xcode tends to encourage layout of files, and considering the huge number of Xcode projects out there that are almost in the right shape, I think we should have some support for this, even if it is opt-in in some easy-ish manner.

[inamiy]

Thank you for reply.
As @mattt points out, this patch will increase complexity, so please feel free to close this issue once backward compatibility is supported.

P.S.
Though this may be another topic, I also want future Xcode to generate swift-package-manager-flavored directory structure by default. Would you take this into consideration as well?

[mattt]

@mxcl That's a very good point. One possible solution would be to delegate responsibility for migrating Xcode projects to Xcode itself. This has the advantage of allowing Xcode to make better decisions based on its own knowledge of existing test targets and the directories they use.

[mxcl]

I think the way we should do this is to have an exclusion mechanism, and asap.