WIP: test #1
Reference in New Issue
Block a user
Delete Branch "wip"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
@@ -14,4 +27,0 @@set(XML_LIBRARIES ${XML_LIBRARIES} ${ICU_LIBRARIES})set(XML_INCLUDE_DIRS ${XML_INCLUDE_DIRS} ${ICU_INCLUDE_DIRS})elseif(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")list(APPEND compiler_definitions WINDOWS)missing
I don't know if this is even needed. Fetching and linking e57 from mavo works fine for all platforms
@@ -9,4 +26,1 @@# Add ICU in Linux Systemsif(${CMAKE_SYSTEM_NAME} STREQUAL "Linux" OR ${CMAKE_SYSTEM_NAME} STREQUAL "Apple")list(APPEND compiler_definitions LINUX)missing
@@ -8,4 +25,2 @@endif()# Add ICU in Linux Systemsif(${CMAKE_SYSTEM_NAME} STREQUAL "Linux" OR ${CMAKE_SYSTEM_NAME} STREQUAL "Apple")Their static xerces-c still needs icu
so you cant just delete this
if find_package is used? I'm not sure, they don't use icu explicitly and to build xerces you need either icu or other transcoder that is selected and should be linked by automatically, isn't it?
static libs, don't include their dependency in the lib itself (usually).
so you will have to either patch up their conan stuff, or link the icu that was used when building the static xerces.
from what I've seen from logs, when you build xerces it always chooses something to link as transcoder (icu or something else) and e57 don't use icu directly, so I bet this whole thing with icu is not necessary. though, can you check xerces linked symbols on linux or mac? IIRC, icu for linux is linked directly in installed xerces lib
it's linked, but the symbols are not included in the lib; unlike a shared lib, a static lib (.a/.lib file) does not know which other (.a/.lib) files are needed; thats the job of the build system, to supply all required lib files to the final exectuable/sharedlib linker
unless you explicitly make a fat static lib, which basically no one does; or a shared lib (which they don't use for their conan setup)
but e57 is built successfully for all platforms on fork when I build it from sources. like is there any difference between this way and using installed version of package that under the hood should have done all the same steps
the lib itself will build fine, but the final linking into an executable will be an issue, when you take their conan xerces-c but not tell it where the icu lib is
well, then it's only relevant if find_package is used (along with conan that loads xerces-c)?
yes, if fetch was used together with a static lib
@@ -6,0 +10,4 @@FetchContent_Declare(xerces-cEXCLUDE_FROM_ALLGIT_REPOSITORY ${XERCES_C_REPO}Undefined variable
@@ -29,3 +29,3 @@target_include_directories(${PROJECT_NAME}PRIVATEPUBLICwhy do you change the include dir to public?
so that target_link_libraries would expose it's includes and I don't need to manually call target_include_directories
i see
can you then please only make the relevant stuff public, we don't need the xml headers when linking opene57
@@ -53,3 +53,3 @@target_include_directories(${PROJECT_NAME}lasPRIVATEPUBLICwhy do you change the include dir to public?
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.