Issue with client-server wrapper and cmake

Simulation Modeling Toolkit (SMTK) Using SMTK
1

@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?

2

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
3

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.

4

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.