When setting the VERSIONINFO resource to embed version information into exe and
DLL files on Windows, override the default LLVM version number values with their
clang equivalents.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239617 91177308-0d34-0410-b5e6-96231b3b80d8

clang/CMakeLists.txt: s/LLVM_INSTALL_PACKAGE_DIR/CLANG_INSTALL_PACKAGE_DIR/ for the standalone configuration.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238628 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: This patch moves all the clang library targets into a ClangTargets export list, and installs it using the CMake install(EXPORT...) command.

Reviewers: rnk

Reviewed By: rnk

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D7623

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238593 91177308-0d34-0410-b5e6-96231b3b80d8

This isn't an actual revert of r237769, it just restores the behavior of
the Clang driver prior to it while completely re-implementing how that
behavior works.

This also re-does the work of making the default OpenMP runtime
selectable at CMake (or configure) time to work in the way all of our
other such hooks do (config.h, configure and cmake hooks, etc.).

I've re-implemented how we manage the '-fopenmp' flagset in an important
way. Now, the "default" hook just makes '-fopenmp' equivalent to
'-fopenmp=<default>' rather than a separate special beast. Also, there
is an '-fno-openmp' flag which does the obvious thing. Also, the code is
shared between all the places to select a known OpenMP runtime and act
on it.

Finally, and most significantly, I've taught the driver to inspect the
selected runtime when choosing whether to propagate the '-fopenmp' flag
to the frontend in the CC1 commandline. Without this, it isn't possible
to use Clang with libgomp, even if you were happy with the serial,
boring way in which it worked previously (ignoring all #pragmas but
linking in the library to satisfy direct calls into the runtime).

While I'm here, I've gone ahead and sketched out a path for the future
name of LLVM's OpenMP runtime (libomp) and the legacy support for its
current name (libiomp5) in what seems a more reasonable way.

To re-enable LLVM's OpenMP runtime (which I think should wait until the
normal getting started instructions are a reasonable way for falks to
check out, build, and install Clang with the runtime) all that needs to
change is the default string in the CMakeLists.txt and configure.ac
file. No code changes necessary.

I also added a test for the driver's behavior around OpenMP since it was
*completely missing* previously. Makes it unsurprising that we got it
wrong.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238389 91177308-0d34-0410-b5e6-96231b3b80d8

configurable in the CMake build. There shouldn't be any change in default
behavior.

Derived from a patch by Daniel Jasper!


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237850 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233016 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225170 91177308-0d34-0410-b5e6-96231b3b80d8

a CLANG_LIBDIR_SUFFIX down from the build system and using that as part
of the default resource dir computation.

Without this, essentially nothing that uses the clang driver works when
building clang with a libdir suffix. This is probably the single biggest
missing piece of support for multilib as without this people could hack
clang to end up installed in the correct location, but it would then
fail to find its own basic resources. I know of at least one distro that
has some variation on this patch to hack around this; hopefully they'll
be able to use the libdir suffix functionality directly as the rest of
these bits land.

This required fixing a copy of the code to compute Clang's resource
directory that is buried inside of the frontend (!!!). It had bitrotted
significantly relative to the driver code. I've made it essentially
a clone of the driver code in order to keep tests (which use cc1
heavily) passing. This copy should probably just be removed and the
frontend taught to always rely on an explicit resource directory from
the driver, but that is a much more invasive change for another day.

I've also updated one test which actually encoded the resource directory
in its checked output to tolerate multilib suffixes.

Note that this relies on a prior LLVM commit to add a stub to the
autoconf build system for this variable.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224924 91177308-0d34-0410-b5e6-96231b3b80d8

'lib' directories in the build. This variable is available now both as
part of the normal LLVM build an as part of a standalone build as I've
added it to the LLVMConfig.cmake output.

With this change we should at least put libraries into the multilib
directory correctly. It is the first step in getting Clang to be
reasonably multilib aware.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224923 91177308-0d34-0410-b5e6-96231b3b80d8

The regex should not accept an empty version number.

The previous attempt at r223106 failed, and the build was still erroring:

  CMake Error at tools/clang/CMakeLists.txt:269 (string):
    string sub-command REGEX, mode REPLACE regex "[^0-9]*([0-9.]*).*" matched
    an empty string.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223333 91177308-0d34-0410-b5e6-96231b3b80d8

If the output of 'ld -v' didn't match the regexes, CMake would previously error
with a message like:

  CMake Error at tools/clang/CMakeLists.txt:269 (string):
    string sub-command REGEX, mode REPLACE regex "[^0-9]*([0-9.]*).*" matched
    an empty string.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223106 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221914 91177308-0d34-0410-b5e6-96231b3b80d8

The Autoconf build already does this, but it was never ported to
CMake. The host linker version affects the flags that Clang pass
to the linker, notably whether it passes -demangle or not.

http://reviews.llvm.org/D6239

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221844 91177308-0d34-0410-b5e6-96231b3b80d8

Trying to fix bots that didn't like the fact that I exported targets
that depended on LLVM without exporting targets from LLVM.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221415 91177308-0d34-0410-b5e6-96231b3b80d8

Installing <prefix>/share/clang/cmake/ClangConfig.cmake makes CMake's
builtin find_package() utility work with Clang. This also allows
downstream consumers of Clang to statically link against libraries like
clangAST and have that pull in dependencies like clangBasic and
LLVMSupport.

See the CMake docs on packages:
http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221411 91177308-0d34-0410-b5e6-96231b3b80d8

The rewrite facility's footprint is small so it's not worth going to these
lengths to support disabling at configure time, particularly since key compiler
features now depend on it.

Meanwhile the Objective-C rewriters have been moved under the
ENABLE_CLANG_ARCMT umbrella for now as they're comparatively heavy and still
potentially worth excluding from lightweight builds.

Tests are now passing with any combination of feature flags. The flags
historically haven't been tested by LLVM's build servers so caveat emptor.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213171 91177308-0d34-0410-b5e6-96231b3b80d8

It turns out this commit was fine. The problem was in the legacy build system (fixed r213010).

This reverts commit r213008.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213014 91177308-0d34-0410-b5e6-96231b3b80d8

Prospectively revert to get one of the many build configurations back working
(presumably the side-by-side+modular CMake config).

This reverts commit r212997.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213008 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212997 91177308-0d34-0410-b5e6-96231b3b80d8

We probably just need to touch LLVM's configure this time to work around the
totally inadequate Makefile build server integration.

This reverts commit r210314.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210320 91177308-0d34-0410-b5e6-96231b3b80d8

This didn't work out on the build servers. Investigating

This reverts commit r210313.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210314 91177308-0d34-0410-b5e6-96231b3b80d8

This will unbreak clang vendor builds as a follow-up to r210238, now that we
can't poke into LLVM's private config.h (nor should the string be exposed by
llvm-config.h).

This hopefully removes for good the last include of LLVM's config.h.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210313 91177308-0d34-0410-b5e6-96231b3b80d8

This is clang's business and LLVM will soon be updated not to perform the check
for us.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210308 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202804 91177308-0d34-0410-b5e6-96231b3b80d8

[CMake] Use target_link_libraries(INTERFACE|PRIVATE) on CMake-2.8.12 to increase opportunity for parallel build.

target_link_libraries(INTERFACE) doesn't bring inter-target dependencies in add_library,
although final targets have dependencies to whole dependent libraries.
It makes most libraries can be built in parallel.

target_link_libraries(PRIVATE) is used to shaared library.
Each dependent library is linked to the target.so, and its user will not see its grandchildren.
For example,

  - libclang.so has sufficient libclang*.a(s).
  - c-index-test requires just only libclang.so.

FIXME: lld is tweaked minimally. Adding INTERFACE in each library would be better thing.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202241 91177308-0d34-0410-b5e6-96231b3b80d8

For now, use both keywords, INTERFACE and PRIVATE via the variable,
  - ${cmake_2_8_12_INTERFACE}
  - ${cmake_2_8_12_PRIVATE}

They could be cleaned up when we introduce 2.8.12.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202239 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201973 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201971 91177308-0d34-0410-b5e6-96231b3b80d8

[CMake] Get rid of explicit dependencies to include/clang/*.inc and introduce CLANG_TABLEGEN_TARGETS.

This does;
  - clang_tablegen() adds each tblgen'd target to global property CLANG_TABLEGEN_TARGETS as list.
  - List of targets is added to LLVM_COMMON_DEPENDS.
  - all clang libraries and targets depend on generated headers.

You might wonder this would be regression, but in fact, this is little loss.
  - Almost all of clang libraries depend on tblgen'd files and clang-tblgen.
  - clang-tblgen may cause short stall-out but doesn't cause unconditional rebuild.
  - Each library's dependencies to tblgen'd files might vary along headers' structure.
    It made hard to track and update *really optimal* dependencies.

Each dependency to intrinsics_gen and ClangSACheckers is left as DEPENDS.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201842 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201319 91177308-0d34-0410-b5e6-96231b3b80d8

The CMake install(DIRECTORY) command documents that it sets permissions
on directories it is asked to install.  Since the <prefix>/include
directory may not be exclusive to the LLVM/Clang installation, we should
not ask CMake to manage permissions of that directory for us.  Instead,
give only our own include/clang and include/clang-c subdirectories to
the install(DIRECTORY) command.

Fixes PR4500. Patch by Brad King.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201076 91177308-0d34-0410-b5e6-96231b3b80d8

CMAKE_MODULE_LINKER_FLAGS can be removed since llvm_add_library(MODULE) adds same flags to MODULE.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201073 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200760 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200759 91177308-0d34-0410-b5e6-96231b3b80d8

Suggested by Stephen Kelly.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200645 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200643 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200302 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200144 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200143 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200133 91177308-0d34-0410-b5e6-96231b3b80d8