Use the FindLibEdit.cmake module from LLDB to properly control where
the libedit libraries are searched for and linked from as well as where
the headers come from. This uses the standard mechanisms which allows
users to control where libedit is pulled from (which is important for
cross-compilation).
This second version is more aggressive about pruning the libedit
handling. The Ubuntu 14.04 version of libedit does not have
`histedit.h`, and the intent is to rely on that to determine if we have
unicode support or not.
The annotation must precede the declaration to which it appertains
during the definition. The re-ordering was silently accepted by clang
but is not correct as per the GNU style. This was flagged by GCC 7.
Recent Swift uses 2 as the is-Swift bit when running on newer versions, and 1 on older versions. Since it's difficult or impossible to know what we'll be running on at build time, make the selection at runtime.
The incorrect location of the ABI marker would result in the symbol not being
exposed when building with `cl` as it expects `__declspec(dllexport)` to be
after the return type.
Rather than using the `LINK_LIBRARIES` option, use target_link_libraries
like clang does. Because these are all host tools, there is no name
mangling done for the libraries making this a no-op change.
Mark the exported interfaces in the tool for the `ENABLE_EXPORTS`
to work properly. This fixes the dependency tracking on Windows
and ensures that the tool is not continuously rebuilt.
Tiny start-up time optimization noticed while looking at how we do
PrettyStackTraceProgram. Also add PrettyStackTraceProgram to a few
more of our testing tools, via the new PROGRAM_START macro.
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
The Swift README states that the minimum CMake version required to build the
Swift project is the same as LLVM's: 3.4.3. Bump the minimum version
used by CMake to correspond to the README.
The main action here is to sink the creation of the installation rule for all of
the swift host tools into this API. In a latter commit, I will use this API to
create include and build rules for add_swift_host_tool.
swift-remote-ast has dependencies that cannot be satisfied by all
of the targets Swift supports. Specifically, the Android target is
unable to link libraries that libRemoteAST depends on, such as uuid.
To fix builds for unsupported platforms, only build remoteast-test
for the host platform.
