* add an option to add freestanding to the Darwin platform, so that
to get expected compile behaviours (e.g. setting the install name)
* rework testing configuration to relax assumptions about freestanding
* add a preset to test such configuration (at least for PR testing)
Addresses rdar://85465396
Unfortunately using the convenient "bootstrapping0-all", etc. custom targets does not work.
For some reason it does not cause a dependent file (like libswift's SIL.o) being rebuilt when a depenency (like swift-frontend from the previous bootstrapping stage) changes.
Instead we have to list al library- and executable-targets explicitly.
swiftDarwin and swiftOnoneSupport didn't depend on building the Swift core library.
This was a subtle bug, because the compiler just picked up the module from the SDK instead of the (still building) Swift module.
It only resulted in compiler errors if the SDK swiftinterface was too new to be parsable by the compiler.
* fix a typo which prevented linking the right bootstrapping libs
* build swiftDarwin for bootstrapping
* disable COW checks if built with bootstrapping-with-hostlibs
This adds a missing link directive to the ComCtl32 module. This allows
use of the module without requiring the user to explicitly add the
linked library to the target when building code against this module.
The debug header is used for enumeration of certain DXGI interfaces
related to debugging of the pipeline. Add this to gain access to the
interfaces and some of the global GUIDs associated with it.
The DirectX subsystem may require access to the HLSL compiler for
building the shaders before uploading to the GPU. This is adds to the
modulemap the D3DCompiler module to get access to the compiler.
There is no usermode header which has the DXGI1.6 interfaces included
unfortunately. This adds the interfaces to the module which is required
for IDXGIAdapter4 interface.
Add the extensions for the Direct3D v10 API to enable access to the
newer DXGISwapChain interfaces. Additionally, correct the linking to
ensure that we pick up the v10 version of the import library.
* Fix two issues with the SwiftGlibc module map.
The issues are:
- Today, some submodules in `SwiftGlibc` fail to provide definitions that
they should contain. As a consequence, Swift fails to import some code
that compiles correctly with standalone Clang. As just one example,
including `signal.h` should make the type `pid_t` available, but it
currently does not.
- `SwiftGlibc` is not compatible with the libc++ module map. Trying to
include libc++ headers in a C++ module imported into Swift results in an
error message about cyclic dependencies.
This change fixes both of these issues by making it so that `SwiftGlibc`
no actually longer defines a module map for the glibc headers but merely makes
all of the symbols from those headers available in a module that can be
imported into Swift. C / Objective-C / C++ code, on the other hand, will now
include the glibc headers texually.
For more context on the two issues and this fix, see this forum
discussion:
https://forums.swift.org/t/problems-with-swiftglibc-and-proposed-fix/37594
This change only modifies `glibc.modulemap.gyb` for the time being but
leaves `bionic.modulemap.gyb` and `libc-openbsd.modulemap.gyb` unchanged. The
intent is to fix these in the same way, but it will be easier to do this
in separate PRs that can be tested individually.
Co-authored-by: zoecarver <z.zoelec2@gmail.com>
Co-authored-by: Marcel Hlopko <hlopko@google.com>
In some cases when building the `XAudio` module, we would end up going
down C++ paths:
```
C:\Program Files (x86)\Windows Kits\10\/Include/10.0.17763.0/um/xaudio2.h:61:26: error: 'uuid' attribute is not supported in C
interface __declspec(uuid("2B02E3CF-2E0B-4ec3-BE45-1B2A3FE7210D")) IXAudio2;
^
<module-includes>:29:10: note: in file included from <module-includes>:29:
^
```
Although this works with newer SDKs, it does not work with older SDKs.
Filter out the module for the time being with a requirement on `C++`.
This should be possible to use with `-enable-cxx-interop`.
Add the module definitions for:
- Direct3D v12
- XAudio 2.9
- XInput 1.4
Additionally, add the following, unusable modules:
- DXCore
DXCore requires C++ Support (C++11 or newer to be precise) and is not
yet available until C++ interop can be made to work fully.
The SensorsAPI headers are not part of the Windows umbrella header and
do not get pulled into the module through some transitive set.
Explicitly list the SensorsAPIs contract into the WinSDK modulemap to
allow use of the api contract from Swift.
Both `immdev.h` & `windows.h` include `imm.h`, and sometimes this header gets assigned to the module containing `windows.h` (currently `WinSDK.WinSock2`) instead of the Internationalization submodule
This replaces swiftMSVCRT with swiftCRT. The big difference here is
that the `visualc` module is no longer imported nor exported. The
`visualc` module remains in use for a singular test wrt availability,
but this should effectively remove the need for the `visualc` module.
The difference between the MSVCRT and ucrt module was not well
understood by most. MSVCRT provided ucrt AND visualc, combining pieces
of the old MSVCRT and the newer ucrt. The ucrt module is what you
really wanted most of the time, however, would need to use MSVCRT for
the convenience aliases for type-generic math and the deprecated math
constants.
Unfortunately, we cannot shadow the `ucrt` module and create a Swift SDK
overlay for ucrt as that seems to result in circular dependencies when
processing the `_Concurrency` module.
Although this makes using the C library easier for most people, it has a
more important subtle change: it cleaves the dependency on visualc.
This means that this enables use of Swift without Visual Studio for the
singular purpose of providing 3 header files. Additionally, it removes
the need for the installation of 2 of the 4 support files. This greatly
simplifies the deployment process on Windows.
The MSDN documentation indicates that you should link against the
`Pathcch.lib` import library when using functions from `pathcch.h` which
can also be verified by use functions failing to link due to unresolved
symbols. Add the missing linking to enable autolinking for `WinSDK`.
Currently winver.h gets included into `WinSDK.WinSock2`, however its usages might not be related to sockets, and it requires linking against `Version.Lib`
