Enabling Static Linking on Windows

[jrose (Jordan Rose)]

@compnerd

@jrose

Statically linking several modules' object files into a dynamic library, while still exporting their API. In that case we wouldn't want the other effects of -static anyway, so it's not actually a valid objection.

This however is and interesting point. I didn't consider this aspect at all. How often do you expect this to occur? To educate me, when is this useful? That is, when do you want to build a library as static but re-export its interfaces? I suppose that this problem can be solved (via a DEFs file or an explicit set of /EXPORT: to the linker), so it isn't preventative, just inconvenient.

People keep asking about doing this on Apple platforms to break up their top-level framework into multiple modules, but still be able to distribute a single .framework bundle. (Most likely in that scenario you'd have a top-level module that re-exports the others.) In that case you're only grouping them for your client's convenience, which makes more sense for framework bundles anyway. If you're already distributing a DLL and a .lib and a .swiftmodule or .swiftinterface, distributing several of them doesn't seem like a terrible inconvenience.

@compnerd

@jrose

So maybe it's fine to just go with -static as a driver option

I failed to make this clear in the original post, so I apologize. This is not a new option. This is an existing option being used to inform code generation.

And my response wasn't very clear either :-) I meant "given that we don't have a reason to change the model, we don't need to change the option, and if we're having the option, writing it into the swiftmodule seems fine".