[cmake] Install runtime swiftDemangle pieces.

[drodriguez]

In DLL environments (Windows) a library RUNTIME piece will be the
DLL itself (while the .lib will be the LIBRARY piece). Adding a RUNTIME
destination install swiftDemangle.dll correctly in its expected place.

This was avoiding some tests from running in the Windows CI machines. It
should also allow people use tools like swift-demangle.

The error appeared something like:

lit.py: C:\jenkins\workspace\oss-swift-windows-x86_64\llvm\utils\lit\lit\formats\googletest.py:43: warning: unable to discover google-tests in 'S:\\swift\\unittests\\SwiftDemangle\\.\\SwiftDemangleTests.exe': Command '['S:\\swift\\unittests\\SwiftDemangle\\.\\SwiftDemangleTests.exe', '--gtest_list_tests']' returned non-zero exit status -1073741515. Process output:

/cc @xiaobai (I cannot find you as a reviewer)

[drodriguez]

The Error 87 will probably still happen. The error from 27823 should still happen, as well as 27844 (intentionally not linking those two to avoid problems with the CI bot).

@swift-ci please test Windows platform

[drodriguez]

@swift-ci please smoke test

[jckarter]

Maybe you've configured Windows differently, but swift-demangle, the runtime, and other tools could be statically linking against libswiftDemangle. It was only ever built as a dynamic library for system use on macOS, but there's not much reason to build it as a dynamic library anywhere else. What tests were affected by this?

[drodriguez]

The test that links against this library is the swiftDemangle tests (https://github.com/apple/swift/blob/master/unittests/SwiftDemangle/CMakeLists.txt).

In theory #27844 should also apply to this case and make this work, but since there was a swift_install_in_component, I imagined that the library was being installed intentionally, but the RUNTIME was missing because it such a Windows specific thing.

I double-checked in my Linux build and it seems that it is also being installed for Linux, and it does also appear in the official toolchains for Ubuntu. It seems that #12705 removed the restriction of not being build for non-Apple targets.

[jckarter]

(Just to be clear, this patch is fine for the situation as is, and don't take my questions as reasons to stop committing it.)

Could the unit tests also link against the static variant? libswiftDemangle doesn't have much of a useful stable API. I don't know what @compnerd's reasons were for enabling the build on Linux, but it seems like an attractive nuisance to do so.

[drodriguez]

I think there's two set of tests: unittests/Basic/DemangleTest.cpp (part of SwiftBasicTests) uses the static library; while unittests/SwiftDemangle/DemangleTest.cpp is actually testing the dynamic library.

I will wait until Saleem answer. I think if we intend to install the library, we might need to provide headers, which as far as I see right now, are not installed at all (which makes the library useless).

[compnerd]

This should be installed - it is so that users have a way to use the APIs to actually detangle the symbol from a given distribution of the toolchain without having to resort to swift-demangle. This is sorta similar to what libc++abi provides __cxa_demangle.

[jckarter]

Sure, but you can do that with the static library, and then tools linking against libswiftDemangle won't be subject to breakage in libswiftDemangle's unstable API. The fact that it shipped as a dynamic library on Apple platforms is an accident.