Teach the Makefile build system to generate and install CMake modules
LLVMConfig.cmake and LLVMConfigVersion.cmake so that applications that
build with CMake can use 'find_package(LLVM)' even when LLVM is not
built with CMake. These modules tell such applications about available
LLVM libraries and their dependencies.
Run llvm-config to generate the list of libraries and use the results of
llvm-build to generate the library dependencies. Use sed to perform
substitutions in the LLVMConfig.cmake.in and LLVMConfigVersion.cmake.in
sources that our CMake build system uses.
Teach the Makefile build system to generate the LLVMExports.cmake file
with content similar to that produced by the CMake install(EXPORT)
command. Extend llvm-build with an option to generate the library
dependencies fragment for this file.
Contributed by Brad King.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201053 91177308-0d34-0410-b5e6-96231b3b80d8
FIXME: Host's llvm-config is not generated. It's for target's.
Host tools, aka "BuildTools", in utils, do not require llvm-config to build.
For example with --host=i686-pc-mingw32 --build=linux,
$ BuildTools/Release+Asserts/bin/llvm-config --libs support
-lLLVMSupport
-lpthread -lshell32 -lpsapi -limagehlp -lm
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197382 91177308-0d34-0410-b5e6-96231b3b80d8
infrastructure.
This was essentially work toward PGO based on a design that had several
flaws, partially dating from a time when LLVM had a different
architecture, and with an effort to modernize it abandoned without being
completed. Since then, it has bitrotted for several years further. The
result is nearly unusable, and isn't helping any of the modern PGO
efforts. Instead, it is getting in the way, adding confusion about PGO
in LLVM and distracting everyone with maintenance on essentially dead
code. Removing it paves the way for modern efforts around PGO.
Among other effects, this removes the last of the runtime libraries from
LLVM. Those are being developed in the separate 'compiler-rt' project
now, with somewhat different licensing specifically more approriate for
runtimes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191835 91177308-0d34-0410-b5e6-96231b3b80d8
Previously it was able to match 'I' anywhere in the filenames of the svn info results instead of just files that where ignored or unknown to svn. This would cause 'make update' to infinitely recurse if a file was modified with I anywhere in its name since svn info would return a Path pointing to the llvm root for those files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185539 91177308-0d34-0410-b5e6-96231b3b80d8
Use a simple recursive bash function to search for svn repos for the 'make
update' target thus including projects like clang-tools-extra.
Reviewers: bkramer, echristo
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173650 91177308-0d34-0410-b5e6-96231b3b80d8
I also moved the SDKROOT setting into the make flags, since clearing it from
the environment isn't good enough to override a setting on the make command
line. That hasn't been a problem but it could be, and it's good to be
consistent with the way UNIVERSAL_SDK_PATH is handled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164565 91177308-0d34-0410-b5e6-96231b3b80d8
My previous change to install llvm-config-host for cross-builds resulted
in that file being installed even when the normal llvm-config was not
installed, e.g., when building the install-clang target. Daniel suggested
this alternative, which solves the immediate problem and also avoids the gunk
in the top-level makefile.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156448 91177308-0d34-0410-b5e6-96231b3b80d8
Now that llvm-config is a binary instead of a script the version installed
during a cross compiled build cannot be run from the host. When cross
compiling, install a separate llvm-config-host that will run on the host.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155164 91177308-0d34-0410-b5e6-96231b3b80d8
Original commit message:
llvm-config: Replace with C++ version (was llvm-config-2).
- Reapply of r144300, with lots of fixes/migration easement in between.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145582 91177308-0d34-0410-b5e6-96231b3b80d8
When I did this before it broke a buildbot that was testing that target, but
we've removed that buildbot now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145519 91177308-0d34-0410-b5e6-96231b3b80d8
TARGETS_TO_BUILD variables to build tools submake, and also tweak echo command
to indicate when we are compiling/etc build tools.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144419 91177308-0d34-0410-b5e6-96231b3b80d8
some more of the explicit dependencies. I'm staging things more slowly this time
in case there is more unanticipated fallout.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144323 91177308-0d34-0410-b5e6-96231b3b80d8
cross build, so that a native version of clang-tblgen is available.
Should unbreak Clang cross build.
Also disable Polly for the native tool build, since it depends on
external libraries which may not be available, and it isn't required
anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141454 91177308-0d34-0410-b5e6-96231b3b80d8
The problems that llvmc solved have largely been subsumed with the
tasks that the clang driver can accomplish, but llvmc lacks flexibility
and depends too heavily on the EOL'd llvm-gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140093 91177308-0d34-0410-b5e6-96231b3b80d8
If enabled, this will attempt to use the CC_LOG_DIAGNOSTICS feature I dropped
into Clang to print a log of all the diagnostics generated during an individual
build (from the top-level). Not sure if this will actually be useful, but for
now it is handy for testing the option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129312 91177308-0d34-0410-b5e6-96231b3b80d8
builds to "Release". The default build is unchanged (optimization on,
assertions on), however it is now called Release+Asserts. The intent
is that future LLVM releases released via llvm.org will be Release builds
in the new sense, i.e. will have assertions disabled (currently they have
assertions enabled, for a more than 20% slowdown). This will bring them
in line with MacOS releases, which ship with assertions disabled. It also
means that "Release" now means the same things in make and cmake builds:
cmake already disables assertions for "Release" builds AFAICS.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107758 91177308-0d34-0410-b5e6-96231b3b80d8
