Issue with client-server wrapper and cmake

@ben.boeckel @tj.corona I’m having an issue adding a Registrar class to smtk/extension/vtk/source… when CMake runs, it complains:

-- Configuring done
CMake Error at /stage/build/cmb/superbuild/superbuild/paraview/build/lib/cmake/paraview-5.7/vtkModuleWrapClientServer.cmake:81 (add_custom_command):
  Attempt to add a custom rule to output

    /stage/build/smtk/4/smtk/extension/paraview/server/plugin/CMakeFiles/RegistrarClientServer.cxx.rule

  which already has a custom rule.
Call Stack (most recent call first):
  /stage/build/cmb/superbuild/superbuild/paraview/build/lib/cmake/paraview-5.7/vtkModuleWrapClientServer.cmake:140 (_vtk_module_wrap_client_server_sources)
  /stage/build/cmb/superbuild/superbuild/paraview/build/lib/cmake/paraview-5.7/vtkModuleWrapClientServer.cmake:305 (_vtk_module_wrap_client_server_library)
  /stage/build/cmb/superbuild/superbuild/paraview/build/lib/cmake/paraview-5.7/ParaViewPlugin.cmake:979 (vtk_module_wrap_client_server)
  smtk/extension/paraview/server/plugin/CMakeLists.txt:4 (paraview_add_plugin)


-- Generating done

I ended up building a custom CMake to print out more information about what’s happening… for some reason the vtkModuleWrapClientServer CMake code wants to output a wrapper for the class in smtk/extension/vtk/source into the smtk/extension/paraview/server directory (which already has a wrapper for a class of the same name, causing the conflict). The custom command lines being generated are

    ParaView::WrapClientServer
    @/stage/build/smtk/4/smtk/extension/paraview/server/plugin/CMakeFiles/smtkPVServerExt-client-server.$<CONFIGURATION>.args
    -o
    /stage/build/smtk/4/smtk/extension/paraview/server/plugin/CMakeFiles/RegistrarClientServer.cxx
    /stage/source/smtk/4/smtk/extension/paraview/server/Registrar.h
    --types
    /stage/build/smtk/4/lib/vtk/hierarchy/SMTKParaViewVTKModules/smtkPVServerExt-hierarchy.txt

vs

    ParaView::WrapClientServer
    @/stage/build/smtk/4/smtk/extension/paraview/server/plugin/CMakeFiles/vtkSMTKSourceExt-client-server.$<CONFIGURATION>.args
    -o
    /stage/build/smtk/4/smtk/extension/paraview/server/plugin/CMakeFiles/RegistrarClientServer.cxx
    /stage/source/smtk/4/smtk/extension/vtk/source/Registrar.h
    --types
    /stage/build/smtk/4/lib/vtk/hierarchy/SMTKVTKModules/vtkSMTKSourceExt-hierarchy.txt

You can see the second one is incorrect (the -o ... path is wrong). I don’t see why ParaView’s wrapper generator rule (in lib/cmake/paraview-5.7/vtkModuleWrapClientServer.cmake) would generate bad output paths. Do you?

No, that path is right. ClientServer sources are all stuffed into CMakeFiles where the vtk_module_wrap_client_server is called. I guess we could use a subdirectory per CS library instead.

This assumption had been OK because VTK already has a “no headers can conflict” because of the “dump everything in one directory” pattern done there. Python and Java wrappers should do the same thing.

The solution would be to change _vtk_client_server_source_output to have a ${_vtk_client_server_library_name}CS subdirectory in there. Similar for the other wrappers.

1 Like

That might still have been OK if fully-qualified names (including namespaces) were used.

That’s probably easier than extracting namespaces and adding those to paths. I’ve submitted PV MR 3791 to do this.

The output file needs to be determined at configure time; we can’t read the C++ code to figure out the symbol name at that point reliably.

Privacy Notice