Cmake error with add_subdirectory in plugin

Development
1

Hello

I’m working on a plugin for a reader (GenericIO) that depends on other libraries (blosc and SZ). So, in the CMakeLists.txt, I have add_subdirectory(GIO/thirdparty), where blosc is found. Part of the CMakelists.txt there is as follows:

add_library(compression STATIC ${BLOSC_Sources} ${SZ_Sources})
set_property(TARGET compression PROPERTY C_STANDARD 99)
target_include_directories(compression PRIVATE ${BLOSC_include_dirs} ${SZ_include_dirs})
target_include_directories(compression INTERFACE 
    blosc
    SZ/sz/include
    )

target_compile_definitions(compression PRIVATE HAVE_LZ4 HAVE_SNAPPY HAVE_ZLIB HAVE_ZSTD)
if(OpenMP_FOUND)
    target_link_libraries(compression PRIVATE OpenMP::OpenMP_C OpenMP::OpenMP_CXX)
endif()

and then the main CMakeLists: has target_link_libraries(LANL_GenericIO PRIVATE compression). Whenever I run cmake, I get:

CMake Error: install(EXPORT “GenericIOReader” …) includes target “LANL_GenericIO” which requires target “compression” that is not in any export set.

CMake Error in Plugins/GenericIOReader/CMakeLists.txt:
export called with target “LANL_GenericIO” which requires target
“compression” that is not in any export set.

What could I be doing wrong? This is based on CMakeLists.txt · octree · hacc / GenericIO · GitLab where there are no issues in the CMake.

2

The CMake code for GIO/thirdparty needs to work with the way we export symbols from ParaView. This is usually as easy as _vtk_module_apply_properties(tgtname) and _vtk_module_install(tgtname).

Note that if this is intended for ParaView itself, we have other, preferred mechanisms, for dealing with third party code. Ideally it would just be find_package(blosc) and find_package(sz) and using the targets they provide, but failing that, these will need their symbols mangled as we build blosc as part of the ParaView Superbuild for ADIOS and if the symbols are the same name, we’re asking for trouble when this plugin is loaded.

3

The reason I am not using find_package for BLOSC and SZ is so that we can take directly what is in the GenericIO git repo and put it directly in ParaView. Is that going to be an issue for ParaView.

That got rid of the error but I’m now seeing something else now when I try to load a file with the GenericIO plugin

bin/paraview: symbol lookup error: /home/pascal/projects/paraview_build/lib/paraview-5.11/plugins/GenericIOReader/GenericIOReader.so: undefined symbol: _ZN14vtkGenIOReader11SetFileNameEPc

and it quits.

Would that be something related to CMake too?

4

Yes. We cannot ship symbols that may conflict with other sources of these libraries. This could technically work if ParaView ships a BLOSC, SZ, and GenericIO SDKs with ParaView so everyone can agree on a single source for the relevant symbols, but since BLOSC is needed by ADIOS and ParaView builds against ADIOS, that is a dependency cycle.

Just to note, we will also need to mangle GenericIO’s symbols for that matter as well. Is there a reason we cannot just use find_package(GenericIO) and provide it via the superbuild (it looks like we already do, but probably a 2016 vintage snapshot)?

It looks like there’s a method that is not implemented on vtkGenIOReader, namely SetFileName(char*). It looks like a vtkSetGetMacro kind of function, but if it is manual, it seems to be missing from the relevant .cxx file.

5

I accidentally deleted setFileName when I was doing some cleanup. Bringing that back got rid of the error.

Yes. We cannot ship symbols that may conflict with other sources of these libraries. This could technically work if ParaView ships a BLOSC, SZ, and GenericIO SDKs with ParaView so everyone can agree on a single source for the relevant symbols, but since BLOSC is needed by ADIOS and ParaView builds against ADIOS, that is a dependency cycle.

I see. For now, I’ll just keep what I have for development and then go for the find_package once the plugin is ready.

Just to note, we will also need to mangle GenericIO’s symbols for that matter as well. Is there a reason we cannot just use find_package(GenericIO) and provide it via the superbuild (it looks like we already do, but probably a 2016 vintage snapshot)?

What I’m doing is upgrading the GenericIO plugin that I put in 2016. I’m calling it 1.1 :). So, it should have the same structure. In 2016, compression was not used that much, so I ditched the BLOSC option. Now, it’s being used and SZ is in the reader as well as an octree.