For now, its user is configure_lit_site_cfg().

llvm-svn: 212314

llvm-svn: 212313

llvm-svn: 209308

  - LLVMSupport.dll
  - libLLVMSupport.dll.a

llvm-svn: 205969

llvm-svn: 202862

llvm-svn: 202510

llvm-svn: 202454

FIXME: It may be PRIVATE since SO knows its dependent libs.
llvm-svn: 202261

[CMake] Move LLVMBUILD_LIB_DEPS stuff from add_llvm_library (and LLVm-Config) to llvm_add_library to centralize target_link_libraries.

llvm-svn: 202260

[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.
llvm-svn: 202241

llvm-svn: 201932

http://www.cmake.org/Bug/view.php?id=14747

llvm-svn: 201855

[CMake] Introduce "llvm_add_library(SHARED STATIC)" to build both shared lib and static lib simulataneously.

  llvm_add_library(foo SHARED STATIC
    DEPENDS <dependent targets...>
    LINK_LIBS <required libraries...>
    )

It generates both foo (foo.so) and foo_static(foo.a) and both of them depend on DEPENDS and LINK_LIBS.
Then, also obj.foo is generated. obj.foo depends on DEPENDS, but doesn't depend on LINK_LIBS.

llvm-svn: 201854

On unsupported platforms, llvm_add_library(MODULE) doesn't create any targets.
Caller may be responsible to check and add extra target properties.

llvm-svn: 201320

llvm-svn: 201318

[CMake] llvm_add_library(MODULE) may use CMAKE_MODULE_LINKER_FLAGS instead of target property LINK_FLAGS.

I mis-dropped Darwin's link flags (in clang side) since r201073.

llvm-svn: 201317

[CMake] llvm_add_library: Add handling of the parameter ADDITIONAL_HEADERS to pass through to process_source.

I was insightless then about unknown optional parameters.
(Consider that LINK_LIBS foo bar ADDITIONAL_HEADERS qux quux)

Suggested by Michael Kruse. Thanks!

llvm-svn: 201283

llvm-svn: 201077

  - MODULE;SHARED;STATIC
      STATIC by default w/o BUILD_SHARED_LIBS.
      SHARED by default w/  BUILD_SHARED_LIBS.
  - OUTPUT_NAME name
      Corresponds to OUTPUT_NAME in target properties.
  - DEPENDS targets...
      Same semantics as add_dependencies().
  - LINK_COMPONENTS components...
      Same as the variable LLVM_LINK_COMPONENTS.
  - LINK_LIBS lib_targets...
      Same semantics as target_link_libraries().
  - ADDITIONAL_HEADERS (implemented in LLVMProcessSources)
      May specify header files for IDE generators.

I suggest llvm_add_library() may be used for inter-project add_library stuff
and also suggest add_***_library() may be used project-specific.

Please be patient that llvm_add_library might be ambiguous against add_llvm_library.

llvm-svn: 201072

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

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

llvm-svn: 200557

I accidentally mis-dropped LLVM_COMPILE_FLAGS in r200301. Sorry for that.

llvm-svn: 200499

[CMake] llvm_update_compile_flags(name) doesn't require source files. TARGET PROPERTY SOURCES has them.

llvm-svn: 200311

[CMake] Enhance llvm_update_compile_flags(name sources) to handle 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

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: 200228

llvm-svn: 200134

  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

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

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

[CMake] Introduce llvm_update_compile_flags(target_name) to update compile flags in target properties.

FIXME: Just add_unittest() is using it.
FIXME: Cooperate with source properties.
llvm-svn: 198683

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

llvm-svn: 198335

[CMake][VS][XCode] Restruct the output directory layout more comfortable, ${BINARY_DIR}/${BUILD_MODE}/(bin|lib)

We have been seeing nasty directory layout with CMake multiconfig, such as,
  bin/Release/clang.exe
  lib/clang/3.x/...
  lib/Release/clang/3.x/.. (duplicated)

Move the layout similar to autoconf's;
  Release/bin/clang.exe
  Release/lib/clang/3.x/...

Checked on Visual Studio 10. Could you guys please confirm my change on XCode(and other multiconfig builders)?

Note: Don't set variables CMAKE_*_OUTPUT_DIRECTORY any more, or a certain builder, for eaxample, msbuild.exe, would be confused.
llvm-svn: 198205

 

llvm-svn: 198203