| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 201054
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 201053
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Teach each package configuration file to load the LLVMExports file for
its corresponding tree. This will allow application CMake code to use
logical library and executable target names from LLVM as if they were in
our own build process (e.g. LLVMSupport). CMake will have enough
information to propagate LLVM library link dependencies automatically
while configuring applications.
Contributed by Brad King.
llvm-svn: 201051
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Record every logical target that we install with install(TARGETS) in a
global LLVM_EXPORTS property. Then use the export(TARGETS) command to
provide a "LLVMExports.cmake" file that exports logical targets for
import into applications directly from our build tree.
The "LLVMExports.cmake" file is not meant for direct inclusion by
application code but should be included by "LLVMConfig.cmake" in a
future change.
Contributed by Brad King.
llvm-svn: 201050
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the install(TARGETS) command EXPORT option for every library and
executable that we install with LLVM. Then use the install(EXPORT)
command to provide a "LLVMExports.cmake" file that exports logical
targets for import into applications from our install tree.
The "LLVMExports.cmake" file is not meant for direct inclusion by
application code but should be included by "LLVMConfig.cmake" in a
future change.
Contributed by Brad King.
llvm-svn: 201049
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create separate package configuration files "LLVMConfig.cmake" for the
LLVM build and install trees so that each can have information specific
to its tree. Configure each with the corresponding include, lib, and
cmake directories. Include the "LLVM-Config" API modules directly from
the configured cmake modules directory.
In the install tree, compute the installation prefix relative to the
file location. In the build tree, provide information specific to the
build tree for use by tools like Clang that can build externally against
the LLVM build tree. Prefix such values in "LLVM_BUILD_" and comment
them as such.
Contributed by Brad King.
llvm-svn: 201048
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not modify this value on the application's behalf and just ensure API
modules are always available next to the LLVMConfig module. This is
already the case in the install tree so use file(COPY) to make it so in
the build tree. Include the LLVM-Config API module from next to the
LLVMConfig location.
Contributed by Brad King.
llvm-svn: 201047
|
|
|
|
|
|
|
|
|
| |
Use a LLVM_INSTALL_PACKAGE_DIR variable to hold the path and reference
it where necessary.
Contributed by Brad King.
llvm-svn: 201046
|
|
|
|
|
|
|
|
| |
CMake won't expand the dependency graph for us if the dependencies are in
another project, which leads to link errors in the standalone build.
This is a refinement of r200765.
llvm-svn: 200812
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r200744 moved this into cmake/config-ix.cmake, so that it would happen very
early in the build process. However, standalone builds of Clang and other
external projects never include this file (which is correct).
Now, -stdlib=libc++ and the LLVM_COMPILER_IS_GCC_COMPATIBLE option are
both set in a new include file, HandleLLVMStdlib, which is included by
both config-ix.cmake and HandleLLVMOptions.cmake. This preserves existing
behavior for projects relying on HandleLLVMOptions and still does the
right thing for builds of LLVM itself.
llvm-svn: 200811
|
|
|
|
|
|
|
|
| |
CMake's target_link_libraries() will manage dependencies.
Configuration time may be reduced by a few seconds.
llvm-svn: 200765
|
|
|
|
|
|
| |
introduce llvm_map_components_to_libnames and llvm_expand_dependencies.
llvm-svn: 200764
|
|
|
|
| |
llvm-svn: 200763
|
|
|
|
|
|
|
|
|
| |
In trunk, every users assume add_llvm_loadable_module as "loadable module" and no one sets neither SHARED, ... nor also MODULE!
Unfortunately, all loadable modules were linked as not "MODULE" but "SHARED".
If this change caused any regressions, I wish guys to fix it properly. ;)
llvm-svn: 200762
|
|
|
|
|
|
| |
-fno-function-sections in a different way.
llvm-svn: 200745
|
|
|
|
|
|
|
|
|
|
|
|
| |
header search
If LLVM_ENABLE_LIBCXX is specified, we should append -stdlib=libc++ to build
flags as early as possible, in particular, before we check for header presence
(as -stdlib=libc++ modifies header lookup rules). Otherwise we can find a header
at configure time (w/o -stdlib=libc++) but fail to find it at build time
(with -stdlib=libc++). See PR18569 for more details.
llvm-svn: 200744
|
|
|
|
|
|
|
|
|
| |
include_directories()."
It missed include/llvm/Target. Could I avoid GLOB_RECURSE anyways? :(
FYI, I intended to prune ${LLVM_MAIN_INCLUDE_DIR} in TableGen.cmake in r200150.
llvm-svn: 200730
|
|
|
|
|
|
|
|
|
| |
the compiler.
This will disable -ffunction-sections in older versions of Clang where it
breaks build of sanitizer runtime library.
llvm-svn: 200695
|
|
|
|
| |
llvm-svn: 200644
|
|
|
|
| |
llvm-svn: 200557
|
|
|
|
| |
llvm-svn: 200556
|
|
|
|
|
|
| |
I accidentally mis-dropped LLVM_COMPILE_FLAGS in r200301. Sorry for that.
llvm-svn: 200499
|
|
|
|
| |
llvm-svn: 200498
|
|
|
|
|
|
| |
PROPERTY SOURCES has them.
llvm-svn: 200311
|
|
|
|
|
|
| |
It is the final step to deprecate contextual CMAKE_CXX_FLAGS.
llvm-svn: 200303
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM_REQUIRES_EH and LLVM_REQUIRES_RTTI.
LLVM_REQUIRES_EH implies LLVM_REQUIRES_RTTI. It is as same behavior as Makefile.rule's.
llvm/examples/ExceptionDemo is affected. (It was built with -fno-rtti.)
For MSVC, Remove flags like "/EHsc /GR" in HandleLLVMOptions, or CL.EXE complains with flags like "/GR /GR-".
llvm_update_compile_flags() updates source file property if the target contains *.c.
COMPILE_FLAGS in target properties affects both C++ and C!
LLVM_NO_RTTI is deprecated. It was introduced by me and was my mistake.
llvm-svn: 200301
|
|
|
|
|
|
| |
to CMAKE_C_FLAGS.
llvm-svn: 200300
|
|
|
|
|
|
|
|
| |
With this tweaks, also unittests are compiled with -ffunction-sections.
It's hard to control contextual CMAKE_CXX_FLAGS. We should get rid of twiddling it as possible.
llvm-svn: 200299
|
|
|
|
| |
llvm-svn: 200298
|
|
|
|
| |
llvm-svn: 200228
|
|
|
|
|
|
| |
For now, local_tds and global_tds are integrated to dependent_tds.
llvm-svn: 200150
|
|
|
|
| |
llvm-svn: 200149
|
|
|
|
| |
llvm-svn: 200134
|
|
|
|
|
|
| |
C compilations as well and these flags don't make any sense there.
llvm-svn: 199756
|
|
|
|
| |
llvm-svn: 199753
|
|
|
|
| |
llvm-svn: 199714
|
|
|
|
|
|
| |
I didn't realize that cmake_parse_arguments() would require explicit inclusion.
llvm-svn: 199674
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ADDITIONAL_HEADERS is intended to add header files for IDEs as hint.
For example:
add_llvm_library(LLVMSupport
Host.cpp
ADDITIONAL_HEADERS
Unix/Host.inc
Windows/Host.inc
)
llvm-svn: 199639
|
|
|
|
|
|
|
|
| |
In LLVM build tree, they points corresponding INTDIR.
In Clang standalone tree, they points external dir (llvm-config's --bindir and --libdir).
llvm-svn: 199595
|
|
|
|
| |
llvm-svn: 199592
|
|
|
|
|
|
|
|
| |
accidentally pick that up while using Clang and run into subtle bugs
down the road related to C++11 features not fully implemented in that
version of the standard library.
llvm-svn: 199484
|
|
|
|
|
|
|
|
|
| |
The generation of the native_export_file end up in
several different makefiles. All those makefiles
write the same file, but can be executed concurrently...
and bad things happen!
llvm-svn: 199356
|
|
|
|
|
|
|
|
| |
option with the others in the top level CMakeLists, and put the check in
HandleLLVMOptions. This will also let it be used from the standalone
Clang builds.
llvm-svn: 199149
|
|
|
|
|
|
| |
action by default.
llvm-svn: 199058
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is needed to support the addition of tests for clang loadable plugins.
In clang, plugins are built as modules (bundles on OS X) rather than dynamic
libraries (dylib) so the build system needs to inform lit of the actual
file extension in use, typically '.so' on Unix and '.dll' on Windows.
(LLVM itself should probably switch to this scheme to fix PR14903 once and for
all.)
No change in build output or functionality intended.
llvm-svn: 198746
|
|
|
|
|
|
|
|
| |
flags in target properties.
FIXME: Just add_unittest() is using it.
FIXME: Cooperate with source properties.
llvm-svn: 198683
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of the system default
Summary:
This parameter is required to build C++11 projects (like lld or lldb) on OS X as the default STL does not provide c++ classes.
CC: llvm-commits, triton
Differential Revision: http://llvm-reviews.chandlerc.com/D2381
llvm-svn: 198625
|
|
|
|
| |
llvm-svn: 198528
|
|
|
|
|
|
|
|
|
| |
Plugins need to go in build/Debug/lib as well (rather than build/lib/Debug).
Also, fix the SHLIBDIR path for Xcode, which by default includes Xcode build
settings rather than a simple %(build_mode)s parameter.
llvm-svn: 198344
|
|
|
|
|
|
| |
LIBRARY_OUTPUT_DIRECTORY_${suffix}.
llvm-svn: 198335
|