Do you reference anything from there? I think that we should just drop this if possible. The supplemental libraries don't tend to reach into the sources of the core libraries AFAIK.

*gyb enters chat*

Though, for the purposes of the supplemental libraries, the gyb module should probably reach up into the compiler bits so that each of the supplemental projects don't need to explicitly.

Which options does the comment refer to? I don't see any contradictory options.

@compnerd it was for

$<$<COMPILE_LANGUAGE:Swift>:-explicit-module-build>
$<$<COMPILE_LANGUAGE:Swift>:-enable-builtin-module>

It was mainly a note for myself to confirm I needed both of those compiler flags as I wasn't sure if they contradicted each other. Evan answered my question below

Is this a copy from the core libraries gyb implementation? It really is unfortunate that we do not have a Runtimes/cmake/modules to share some of these through.

@etcwilde - what do you think of creating that?

Yep, it's a copy in the same way we have AvailabilityMacros

I've been doing my best to prevent cross-pollination between the layers.
Worried about folks trying to be overly DRY and ending up with another umbrella add_swift_target_library function with 97 arguments.

These don't conflict. explicit module builds affect how the driver looks up modules, while builtin-module allows libraries that are not part of the core Swift module to use builtins. It's not for use outside of the distribution of standard libraries, but everything in Supplemental is part of that distribution so it's fine.

This seems a remnant from the reference code in SwiftCore -- maybe we can use the project name directly

Namespacing the component with the project name is good. Let's keep the _runtime suffix since this is only installing the runtime library. This will make it easier to split up the install story for different use cases.