LLVM already provides these directories via the LLVMConfig.cmake variable
LLVM_INCLUDE_DIRS, which we are already using to import those directories.
Thus this work is and even worse gives the illusion that we are not delegating
the computation of LLVM's include paths to LLVM (which is really what we are
doing and should be doing).
rdar://26154980
Setting this value is equivalent to setting:
include_directories(${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_CURRENT_SOURCE_DIR})
in all subdirectories. Since these are all macros, this means that we are adding to the configuration
path the root swift directory. There is no reason to do this and will result in
confusion/bugs in the future.
rdar://26154980
This is apart of a series of patches that separates configuration of
llvm/clang/cmark in swift_common_standalone_build_config. Right now each project
has configuration occurring in a mixed up way. By refactoring it becomes much
easier to read the code.
rdar://26154980
This eliminates us setting an LLVM_ prefixed variable in a situation where there is
a viable alternative.
We want to eliminate as many of these as possible since they can cause conflicts
with variables set in LLVMConfig.cmake.
I also added some convenience tablegen functions in AddSwiftTableGen.cmake and
changed all tblgen users to use that instead.
rdar://26154980
This fixes part of the Xcode build by allowing us to avoid having to use cmake
variables with an unexpanded CMAKE_CFG_INTDIR.
Since those variables are not expanded, they point to a non-existant path like:
.../$(CONFIGURATION)$(...)/lib
So finding tablegen fails. In the cross compile case, we still try to find the
native tablegen.
rdar://26154980
There are a couple of things going on in this patch. Lets consider first the
crosscompiling case.
In the cross compiling case, we were already setting LLVM_TOOLS_BINARY_DIR to
the binary dir of the just compiled LLVM (not the native LLVM/clang). This is
exactly what using LLVMConfig.cmake from that just compiled LLVM will set
LLVM_TOOLS_BINARY_DIR.
In the non-cross compiling case, we originally grabbed LLVM_TOOLS_BINARY_DIR
from llvm-config and then used that value to set the NATIVE llvm/clang paths.
rdar://26154980
This was added some time ago in case we want to build clang separate from llvm
just like we do swift. We do not actually support that though.
Currently, this just results in the main llvm binary directory being added for a
second time to the link path (i.e. this work iw asted). Thus just remove the
line but leave in a *NOTE* to deliver the message that this is where the clang
link path in such a case would need to go.
This variable was added in 2015 to set a value that was needed given upstream
changes. In Feb 2016, we started importing LLVMConfig.cmake. LLVMConfig.cmake
provides this value for us. Thus we can remove the dead variable.
rdar://26154980
This bug was in tree before I began to make my changes. I uncovered the bug when
I was thinking about whether or not this line of code was dead and thus looked
at how it was used.
rdar://26154980
Previously in order to support cross-compiling, we were setting these variables
in build-script. Now that we are using LLVMConfig.cmake, passing in these values
are no longer necessary. As an added benefit, Swift when not cross compiling,
does not need to set these variables anyways.
rdar://26154980
Before this patch, we would always set ${product}_PATH_TO_LLVM_{SOURCE,BUILD} to
a value taken from llvm-config. But, turns out we had generated llvm-config
using these values. Thus llvm-config is just giving us back values we already
have.
This commit changes these variables to be precondition variables and doesn't
cause them to be reset.
rdar://26154980
llvm/Support/Compiler.h recently grew a dependency on llvm-config.h. This
pointed out that we were not including the path to the generated header
directory in the build output. Ensure that we have the corresponding -I.
Update the paths that we look in for the cmake modules from LLVM which changed
recently on SVN trunk. Check the old paths first, and if that fails, check the
new path. This permits building against either layout.
The issue is that this was originally done when in-tree builds were the
preferred way of building so LLVM_ENABLE_DOXYGEN would be defined and LLVM would
have found doxygen as well. When one is doing the current preferred standalone
install, the option LLVM_ENABLE_DOXYGEN is not discoverable to the user via an
option with a default argument and the doxygen package is never searched for.
This commit ensures that when building standalone:
1. LLVM_ENABLE_DOXYGEN is defined as an option with a default value of FALSE.
2. The cmake dtrace package is searched for and found.
When we are building standalone, we take these values from LLVM.
This allows `ninja check` to display the lit progress bar when using a
new enough cmake+ninja combination, as it does in LLVM these days.
Swift SVN r27923
Replace ReST-flavored documentation comments with Markdown.
rdar://problem/20180412
In addition to full Markdown support, the following extensions are
supported. These appear as lists at the top level of the comment's
"document". All of these extensions are matched without regard to
case.
Parameter Outlines
------------------
- Parameters:
- x: ...
- y: ...
Separate Parameters
-------------------
- parameter x: ...
- parameter y: ...
- Note:
Parameter documentation may be broken up across the entire comment,
with a mix of parameter documentation kinds - they'll be consolidated
in the end.
Returns
-------
- returns: ...
The following extensions are also list items at the top level, which
will also appear in Xcode QuickHelp as first-class citizens:
- Attention: ...
- Author: ...
- Authors: ...
- Bug: ...
- Complexity: ...
- Copyright: ...
- Date: ...
- Experiment: ...
- Important: ...
- Invariant: ...
- Note: ...
- Postcondition: ...
- Precondition: ...
- Remark: ...
- Remarks: ...
- See: ...
- Since: ...
- Todo: ...
- Version: ...
- Warning: ...
These match most of the extra fields in Doxygen, plus a few more per request.
Other changes
-------------
- Remove use of rawHTML for all markup AST nodes except for those
not representable by the Xcode QuickHelp XSLT - <h>, <hr/>, and of
course inline/block HTML itself.
- Update the doc comment RNG schema to more accurately reflect Xcode
QuickHelp.
- Clean up cmark CMake configuration.
- Rename "FullComment" to "DocComment"
- Update the Swift Standard Documentation (in a follow-up commit)
- Update SourceKit for minor changes and link against cmark
(in a follow-up commit).
Swift SVN r27727
...and rename it to swift_common_llvm_config.
This is the function that acts like llvm_config but handles the LLVM build
being a different configuration from the Swift (or SourceKit) build, which
can be problematic for multi-configuration build schemes like Xcode.
There's also one fix here: LLVM dependencies for dylibs weren't being
properly added. (This is the "SHARED_LIBRARY" case near the bottom.)
Swift SVN r26631
<rdar://problem/20180372>
Build cmark alongside llvm and clang.
If the clone doesn't exist, build-script-impl will clone it in the
workspace. Also update the README and update-checkout scripts.
Swift SVN r26364
