Cmake error when building a ParaView plugin (external library linking)

ParaView Support
1

Hello,

I’m writing a C+±based ParaView plugin and found a strange cmake error at generate step.

To reproduce the problem I’m facing, let’s start from a example (e.g. GitHub - jfavre/ParaViewSalvusPlugin: A C++ plugin for ParaView to read Salvus HDF5 data). It builds fine.

Then if I simply add a target_link_libraries to library Kokkos, in src/Reader/CMakeLists.txt as shown here:

cmake complains with following error message (see below).
What is strange to me is that actually, the Makefiles are well generated; and if I add some code that actually uses Kokkos API, it builds and runs fine; but still this cmake error at generate step persists. I don’t know how to remove it.
I also tried (just for cross-checking) linking to other external third party libraries. It works fine. So I guess there may be something special when linking a paraview plugin to kokkos library ? I don’t know how to investigate that. And again, despite the error message, the plugin can still build ok.

Any help appreciated.

========================================================================
– Found MPI: TRUE (found version “3.1”) found components: C
– Found MPI: TRUE (found version “3.1”)
– Enabled Kokkos devices: OPENMP
– Configuring done
CMake Error in src/CMakeLists.txt:
Evaluation file to be written multiple times with different content. This
is generally caused by the content evaluating the configuration type,
language, or location of object files:

/home/kestenerp/install/visualization/paraview/github/ParaViewSalvusPlugin-pk/_build/src/CMakeFiles/SalvusHDF5Reader-client-server.Release.args

CMake Error in src/Reader/CMakeLists.txt:
Evaluation file to be written multiple times with different content. This
is generally caused by the content evaluating the configuration type,
language, or location of object files:

/home/kestenerp/install/visualization/paraview/github/ParaViewSalvusPlugin-pk/_build/src/Reader/CMakeFiles/SalvusHDF5Reader-hierarchy.Release.args

– Generating done
CMake Generate step failed. Build files cannot be regenerated correctly.

2

Your plugin is named the same as the post-:: part of a module. Rename one of them and it should be fine.

1 Like
3

Ok, I see now. Thanks.

4

I’ve renamed the module, I’ve also modified CMakeLists.txt that builds the module to use vtk_module_find_package(PACKAGE Kokkos) to detect external library. But still the error at generate step is still there and I don’t understand why.

Is there a way to debug the cmake generate step ?

5

Hello,

Let me just take another example directly from Paraview sources, subfolder Examples/Plugins/LagrangianIntegrationModel

It builds fine.
Just for illustrating the problem, if I add those lines:

vtk_module_find_package(
  PACKAGE Kokkos
  )
vtk_module_link(LagrangianExample PRIVATE Kokkos::kokkos)

then the same cmake (from generator) comes again:

CMake Error in Plugin/CMakeLists.txt:
  Evaluation file to be written multiple times with different content.  This
  is generally caused by the content evaluating the configuration type,
  language, or location of object files:

   /home/kestenerp/install/visualization/paraview/github/ParaView/Examples/Plugins/LagrangianIntegrationModel/_build/Plugin/CMakeFiles/LagrangianExample-client-server..args


CMake Error in Plugin/LagrangianExample/CMakeLists.txt:
  Evaluation file to be written multiple times with different content.  This
  is generally caused by the content evaluating the configuration type,
  language, or location of object files:

   /home/kestenerp/install/visualization/paraview/github/ParaView/Examples/Plugins/LagrangianIntegrationModel/_build/Plugin/LagrangianExample/CMakeFiles/LagrangianExample-hierarchy..args

Again, despite the cmake error, the build is ok.

There is obviously something that I didn’t understand about linking a plugin module to an external library.
Can someone help ?

6

That is certainly weird… I notice the ..args in the paths which seems like you have an empty string configuration value? Can you provide the target definition of Kokkos::kokkos?

7

About ..args : the log above was generated without CMAKE_BUILD_TYPE; when add a build type, it doesn’t change the error message.

Regarding the definition of target Kokkos::kokkos, looking at KokkosTargets.cmake in install directory, one can see:

# Create imported target Kokkos::kokkos
add_library(Kokkos::kokkos INTERFACE IMPORTED)

set_target_properties(Kokkos::kokkos PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "Kokkos::kokkoscore;Kokkos::kokkoscontainers;Kokkos::kokkosalgorithms;Kokkos::kokkossimd"
)

all the other Kokkos:: targets are either SHARED or INTERFACE IMPORTED libraries.
I can provide the entire file if needed. Anything particular should be noticed ? One can also see that Kokkos is linking to libdl, could this be a problem (for whatever reason) ?

Is there a way to trace inside cmake to understand how the error is generated ?

8

Yes. Run cmake --trace-expand (and redirect stderr to a file). Searching for the problematic paths should find where they’re being called from.

9

Hello,

I’ve recompiled cmake just to make the error message clearer (and print the difference when conflict happens).

I found the origin of the conflict when generating those files (e.g. LagrangianExample-client-server..args). They are generated for language C and CXX and Kokkos is adding symbol KOKKOS_DEPENDENCE for CXX for compile and link (that’s the difference):

set_target_properties(Kokkos::kokkoscore PROPERTIES
  INTERFACE_COMPILE_DEFINITIONS "\$<\$<COMPILE_LANGUAGE:CXX>:KOKKOS_DEPENDENCE>"
  INTERFACE_COMPILE_FEATURES "cxx_std_17"
  INTERFACE_COMPILE_OPTIONS "\$<\$<COMPILE_LANGUAGE:CXX>:>"
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "Kokkos::HWLOC;Kokkos::LIBDL;OpenMP::OpenMP_CXX"
  INTERFACE_LINK_OPTIONS "\$<\$<LINK_LANGUAGE:CXX>:-DKOKKOS_DEPENDENCE>"
)

This symbol is used by kokkos; when compiling, kokkos actually uses kokkos_launch_compiler to redirect to the actual c++ compiler/linker when needed (e.g. when compiling for Nvidia/Cuda). I’m only using Kokkos::OpenMP backend, but this symbol is always defined for language CXX (and not for C).

I don’t quite understand why this problem only happens now, only when building a paraview plugin.
Is is really necessary to generate those files for C language ? Maybe, that is the root cause of the problem ?

Any suggestion on how to fix that ?

10

Seems to be the case. I’m not sure what makes it get generated per-language though… Is there only the one file(GENERATE) call that mentions this path as an OUTPUT or are there multiple instances in the --trace-expand log?

11

yes, there is only one call to file(GENERATE)
and I noticed that every occurence of file(GENERATE) leads to 2 calls to cmGeneratorExpressionEvaluationFile::Generate, one for C language, one for CXX language.

There error message above correspond to the two occurences where C and CXX generated file disagree.
In my case, the file that is actually used finaly is the one generated using lang=C, the second time, the error message is displayed. So I think there is something wrong, it means if the third party c++ library is defining compilation flags specific for CXX, they will be ignored when building the plugin.

The file(GENERATE) calls that are causing problem are the ones coming from paraview’s :

  • vtkModule.cmake in function _vtk_module_write_wrap_hierarchy
  • vtkModuleWrapClientServer.cmake in function _vtk_module_wrap_client_server_sources

Would it be a solution to modify the calls to file(GENERATE) at those locations by adding CONDITION <expression> where condition would be true only for lang=CXX (since anyway the plugin is written in CXX) ?