2018-05-16 00:30:30 +08:00
|
|
|
# Needed by LLVM's CMake checks because this file defines multiple targets.
|
Fix build warning compiling TestPlugin on Windows and disable Passes plugin stuff on Windows since it fundamentally can't work
Aaron Ballman reported that TestPlugin warned about it using exception handling
without /EHsc flag, and that llvmGetPassInfo() had conflicting export
attributes (dllimport in the header, dllexport in the source file).
/EHsc is because TestPlugin didn't use the llvm_ cmake functions, so
llvm_update_compile_flags didn't get called for the target
(llvm_update_compile_flags explicitly passes /Ehs-c-, which fixes the warning).
Use add_llvm_loadable_module instead of add_library(... MODULE) to fix this.
This also has the side effect of not building the plugin on Windows. That's not
a big problem, since before the plugin was built on Windows, but the test
didn't attempt to load it, due to -DLLVM_ENABLE_PLUGIN not being passed to
PluginsTests.cpp during compilation on Windows. This makes the plugin behavior
consistent with e.g. lib/Transforms/Hello/CMakeLists.txt. (This also
automatically sets LTDL_SHLIB_EXT correctly.)
The dllimport/dllexport warning is more serious: Since LLVM doesn't generally
use export annotations for its code, the only way the plugin could link was by
linking in some LLVM libraries both into the test and the dll, so the plugin
would call the llvm code in the dll instead of the copy in the main executable.
This means globals weren't shared, and things generally can't work. (I think
there's a build config where you can build a LLVM.dll which might work, but
that wasn't how the test was configured. If that config is used, the dll should
still be built, but I haven't checked).
Now that add_llvm_loadable_module is used, LLVM_LINK_COMPONENTS got linked into
both executable and plugin on posix too, so unset it after the executable so
that the plugin doesn't end up with a 2nd copy of things on posix.
https://reviews.llvm.org/D47082
llvm-svn: 332796
2018-05-19 11:05:30 +08:00
|
|
|
set(LLVM_OPTIONAL_SOURCES PluginsTest.cpp TestPlugin.cpp)
|
2018-04-05 23:04:13 +08:00
|
|
|
|
2018-04-26 04:16:24 +08:00
|
|
|
# If plugins are disabled, this test will disable itself at runtime. Otherwise,
|
|
|
|
|
# reconfiguring with plugins disabled will leave behind a stale executable.
|
2018-04-08 04:22:38 +08:00
|
|
|
if (LLVM_ENABLE_PLUGINS)
|
2018-04-26 04:16:24 +08:00
|
|
|
add_definitions(-DLLVM_ENABLE_PLUGINS)
|
|
|
|
|
endif()
|
2018-04-05 23:04:13 +08:00
|
|
|
|
Fix build warning compiling TestPlugin on Windows and disable Passes plugin stuff on Windows since it fundamentally can't work
Aaron Ballman reported that TestPlugin warned about it using exception handling
without /EHsc flag, and that llvmGetPassInfo() had conflicting export
attributes (dllimport in the header, dllexport in the source file).
/EHsc is because TestPlugin didn't use the llvm_ cmake functions, so
llvm_update_compile_flags didn't get called for the target
(llvm_update_compile_flags explicitly passes /Ehs-c-, which fixes the warning).
Use add_llvm_loadable_module instead of add_library(... MODULE) to fix this.
This also has the side effect of not building the plugin on Windows. That's not
a big problem, since before the plugin was built on Windows, but the test
didn't attempt to load it, due to -DLLVM_ENABLE_PLUGIN not being passed to
PluginsTests.cpp during compilation on Windows. This makes the plugin behavior
consistent with e.g. lib/Transforms/Hello/CMakeLists.txt. (This also
automatically sets LTDL_SHLIB_EXT correctly.)
The dllimport/dllexport warning is more serious: Since LLVM doesn't generally
use export annotations for its code, the only way the plugin could link was by
linking in some LLVM libraries both into the test and the dll, so the plugin
would call the llvm code in the dll instead of the copy in the main executable.
This means globals weren't shared, and things generally can't work. (I think
there's a build config where you can build a LLVM.dll which might work, but
that wasn't how the test was configured. If that config is used, the dll should
still be built, but I haven't checked).
Now that add_llvm_loadable_module is used, LLVM_LINK_COMPONENTS got linked into
both executable and plugin on posix too, so unset it after the executable so
that the plugin doesn't end up with a 2nd copy of things on posix.
https://reviews.llvm.org/D47082
llvm-svn: 332796
2018-05-19 11:05:30 +08:00
|
|
|
set(LLVM_LINK_COMPONENTS Support Passes Core)
|
2018-05-18 20:42:30 +08:00
|
|
|
add_llvm_unittest(PluginsTests
|
|
|
|
|
PluginsTest.cpp
|
|
|
|
|
)
|
2018-04-26 04:16:24 +08:00
|
|
|
export_executable_symbols(PluginsTests)
|
2018-10-17 18:36:23 +08:00
|
|
|
target_link_libraries(PluginsTests PRIVATE LLVMTestingSupport)
|
2018-04-05 23:04:13 +08:00
|
|
|
|
2018-09-14 04:24:36 +08:00
|
|
|
set(LLVM_LINK_COMPONENTS)
|
2018-12-21 06:04:08 +08:00
|
|
|
add_llvm_library(TestPlugin MODULE
|
2018-05-18 20:42:30 +08:00
|
|
|
TestPlugin.cpp
|
|
|
|
|
)
|
2018-04-05 23:04:13 +08:00
|
|
|
|
Fix build warning compiling TestPlugin on Windows and disable Passes plugin stuff on Windows since it fundamentally can't work
Aaron Ballman reported that TestPlugin warned about it using exception handling
without /EHsc flag, and that llvmGetPassInfo() had conflicting export
attributes (dllimport in the header, dllexport in the source file).
/EHsc is because TestPlugin didn't use the llvm_ cmake functions, so
llvm_update_compile_flags didn't get called for the target
(llvm_update_compile_flags explicitly passes /Ehs-c-, which fixes the warning).
Use add_llvm_loadable_module instead of add_library(... MODULE) to fix this.
This also has the side effect of not building the plugin on Windows. That's not
a big problem, since before the plugin was built on Windows, but the test
didn't attempt to load it, due to -DLLVM_ENABLE_PLUGIN not being passed to
PluginsTests.cpp during compilation on Windows. This makes the plugin behavior
consistent with e.g. lib/Transforms/Hello/CMakeLists.txt. (This also
automatically sets LTDL_SHLIB_EXT correctly.)
The dllimport/dllexport warning is more serious: Since LLVM doesn't generally
use export annotations for its code, the only way the plugin could link was by
linking in some LLVM libraries both into the test and the dll, so the plugin
would call the llvm code in the dll instead of the copy in the main executable.
This means globals weren't shared, and things generally can't work. (I think
there's a build config where you can build a LLVM.dll which might work, but
that wasn't how the test was configured. If that config is used, the dll should
still be built, but I haven't checked).
Now that add_llvm_loadable_module is used, LLVM_LINK_COMPONENTS got linked into
both executable and plugin on posix too, so unset it after the executable so
that the plugin doesn't end up with a 2nd copy of things on posix.
https://reviews.llvm.org/D47082
llvm-svn: 332796
2018-05-19 11:05:30 +08:00
|
|
|
# Put plugin next to the unit test executable.
|
2018-04-26 04:16:24 +08:00
|
|
|
set_output_directory(TestPlugin
|
|
|
|
|
BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}
|
|
|
|
|
LIBRARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}
|
|
|
|
|
)
|
2018-05-03 02:57:14 +08:00
|
|
|
set_target_properties(TestPlugin PROPERTIES FOLDER "Tests")
|
2018-09-14 04:24:36 +08:00
|
|
|
|
|
|
|
|
add_dependencies(TestPlugin intrinsics_gen)
|
|
|
|
|
add_dependencies(PluginsTests TestPlugin)
|