Skip to content
  • whitlocb's avatar
    I could not get around build problems related to rendering_visit_vtk depending · 1b475a32
    whitlocb authored
    on avtPlotter on my cmake branch due avt::glew::initialize. I'm not using 
    -unresolved,dynamic_lookup for gcc which lets the linker skip unresolved 
    symbols. I find this is a good test for measuring compatibility with Windows, 
    which is our most strict platform. CMake dependencies will need to remain strict
    to ensure that the code continues to build on Windows.
    
    The problem is where to put avt::glew::initialize. Since it relies on
    state from avtCallbacks, it makes sense to keep it in avt. This is why I did
    not move avt::glew::initialize into rendering_visit_vtk. Anyway, I decided to
    move rendering_visit_vtk and parallel_visit_vtk into the avtPlotter library 
    itself so the vtkMappers can use avt::glew::initialize without introducing bad
    library dependencies. Plot plugins also use avt::glew::initialize but, as plots,
    they already have avtPlotter dependencies so it's okay. Moving 
    parallel_visit_vtk also helps with a library dependency problem for parallel.
    If I remember correctly, it had a dependence on avtPipeline. Coupled with
    Makefile LIBS= updates we can now build in parallel without the 
    -unresolved,dynamic_lookup options on the Mac.
    
    While I was at it, I removed the engine/parstate library, moving MPIXfer into
    the engine. The other part of engine/parstate was deprecated in 1.12.0 so the
    library did not have much reason to exist.
    
    Not much is different from a Linux point of view other than we have 3 fewer
    libraries now.
    
    
    
    git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@8845 18c085ea-50e0-402c-830e-de6fd14e8384
    1b475a32