Conversation
9783473 to
38f7dc7
Compare
| SOVERSION ${Zycore_VERSION_MAJOR}.${Zycore_VERSION_MINOR}) | ||
| VERSION "${Zycore_VERSION}" | ||
| SOVERSION "${Zycore_VERSION_MAJOR}.${Zycore_VERSION_MINOR}" | ||
| DEFINE_SYMBOL "ZYCORE_SHOULD_EXPORT") |
There was a problem hiding this comment.
This renames the default of Zycore_EXPORTS -> ZYCORE_SHOULD_EXPORT.
38f7dc7 to
9319c44
Compare
flobernd
left a comment
There was a problem hiding this comment.
LGTM!
Let's carefully test again after the Zydis follow-up PR.
|
Btw, could you please add something unrelated (must be right below the if (NOT DEFINED CMAKE_ARCHIVE_OUTPUT_DIRECTORY)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})
endif()
if (NOT DEFINED CMAKE_LIBRARY_OUTPUT_DIRECTORY)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})
endif()
if (NOT DEFINED CMAKE_RUNTIME_OUTPUT_DIRECTORY)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})
endif()I found on Windows the After adding the above lines, the libraries (shared and static) are always placed in the top-level binary directory. For |
|
Let's do that in a different PR after we figured out how to best do this in the discussion here. |
|
I'm a bit late, but dropping |
This PR gets rid of the CMake generated
ZycoreExportConfig.hheader. It's annoying to deal with in non-CMake environments because CMake generates it for one specific compiler (so you can't just generate it once and use it everywhere) and also doesn't really provide much that we couldn't just as well detect at compile time.Because the previous exports created by CMake were rather cryptic, I also took the opportunity to rename them:
ZYCORE_STATIC_DEFINE->ZYCORE_STATIC_BUILDZycore_EXPORTS->ZYCORE_SHOULD_EXPORTThere was a third define that we manually defined previously,
ZYCORE_EXPORTS(mind the casing), which was seemingly unused, so I removed it.Because we don't have CI here, I created a branch in the Zydis repo and updated the submodule. Builds just fine, results are here.
Once approved, I'll apply the same changes to Zydis.