Move the check for multi-lang to Native build system.

[dschaefer2]

This allows SwiftBuild to use it's powers to support multiple languages in a target.

The check is moved the SwiftModuleBuildDescription which manages the Swift modules for the Native build system.

Tests are added to ensure the behavior moved and that SwiftBuild can now have targets with C and Swift source files in them.

[dschaefer2]

@swift-ci please test

[jakepetroules]

Awesome first step! How are planning to handle the next stage in the process?

There are separate ClangModule and SwiftModule targets in the package model, that will need to be collapsed somehow, or at minimum SwiftModule needs to be effectively treated as a superset of ClangModule rather than having several mutually exclusive properties as it does now. A bunch of things in the PIF in particular will need to change to accommodate that.

I think it's probably better overall if ClangModule and SwiftModule are collapsed into a single type.

[dschaefer2]

Awesome first step! How are planning to handle the next stage in the process?

There are separate ClangModule and SwiftModule targets in the package model, that will need to be collapsed somehow, or at minimum SwiftModule needs to be effectively treated as a superset of ClangModule rather than having several mutually exclusive properties as it does now. A bunch of things in the PIF in particular will need to change to accommodate that.

I think it's probably better overall if ClangModule and SwiftModule are collapsed into a single type.

Agreed, There isn't much difference between them anyway. Native still depends on them being separate so we'll need to adjust it for that. So maybe we will hold of on that until 6.4++.

The next stage is to get the build settings for bridging header and the generated header in place and take that and this through evolution.

[jakepetroules]

While we could add support for bridging headers, it's orthogonal to the baseline mixed-source targets functionality. It's about importing non-modular content specifically.

I also don't know that there's much use case for a setting to specify the generated header name either, people just use the default and never override it.

[dschaefer2]

Fair. It would be good to know how many people set those settings in Xcode. At the very least, we should support private bridging headers. @_extern is too easy to get wrong. And the biggest complaint I'm trying to address is the need to set up a separate module for a Swift module's C code, i.e. shims, in which case they already are doing the equivalent of a bridging header in the C module's modulemap.

At any rate, those things are easy to add and we need to get in the habit of enhancing the manifest for a better developer experience.

[jakepetroules]

Fair. It would be good to know how many people set those settings in Xcode.

As usual with these sort of questions, I don't think we have any way to know, but my intuition based on my experience is virtually none. It's only ever set to "" to turn off the generation or to $(PRODUCT_MODULE_NAME)-Swift.h, which is what it already is by default.

At the very least, we should support private bridging headers. @_extern is too easy to get wrong.

Yeah, internal bridging headers for sure. That will definitely need package manifest API.

I think we should avoid adding support for re-exported bridging headers given their viral nature.

And the biggest complaint I'm trying to address is the need to set up a separate module for a Swift module's C code, i.e. shims, in which case they already are doing the equivalent of a bridging header in the C module's modulemap.

Yup, this patch alone plus some minor internal refactoring should do that without needing any new API, for the modularized case.

[dschaefer2]

@swift-ci please test windows

[dschaefer2]

@swift-ci please test

[dschaefer2]

@swift-ci please test windows