Provide a higher level build setting than MACH_O_TYPE

[cmcgee1024]

Currently, SwiftBuild uses this setting to determine whether the linker is producing an executable (mh_executable), static library (staticlib), dynamic library (mh_dylib), or combining multiple object files into a single object file (mh_object). Note that the latter setting is not used to compile a source file to an object file, it is combining multiple object files into a single one, a process that is sometimes called “partial linking”.

The default macOS linker ld64 supports partial linking with a “-r” flag, and Linux ld/gold supports a very similar mode with the same flag. However, the Visual Studio Windows linker (link.exe) does not support this mode at all. You can compile a static “.lib” from multiple object files, but this lib cannot be used in place of an object file (.obj) further along, much like how you can’t use archives “.a” files in place of objects “.o” on macOS or Linux.

A new higher level abstraction is necessary to allow the PIF to model the steps in a platform neutral, and executable file format (ELF/PE) way.

[cmcgee1024]

A proposal is to introduce a new build setting called "BINARY_TYPE" that would be platform independent, allowing SwiftBuild to take the correct action in each platform.

For Windows, one might consider creating .lib archives for each target, a bit like the MACH_O_TYPE setting of staticlib for targets so that the linker can use them without partial linking. For dynamic products there is a wholearchive that could be used to get all of the symbols into the product. Because this only affects intermediates this could be a viable option on Windows, and possibly Linux too with .a archives in place of .lib.

macOS will probably need to retain much of the existing behaviour because of the handling of Objective-C, but the new "BINARY_TYPE" should be designed in such a way that SwiftBuild will be able to use the existing approach.