If I am building paraview in addition to my plugins (which in the long
run works out better) then I use the technique where you use the
"PARAVIEW_EXTRA_EXTERNAL_MODULE" then point that towards your project
that has ${project_name}ParaViewImport.cmake file. This way all your
plugins are deposited in the paraview build directory and will get
installed when you do a "make install". Then you can simply bundle up
the build directory and put that on another computer. Has always
worked for me so I am hoping that still works in the future.
-----
Mike JacksonOn Tue, Mar 24, 2009 at 5:06 PM, Marcus D. Hanwell <[email protected]> wrote: > Berk Geveci wrote: >> Forwading from developers list. >> >> >> ---------- Forwarded message ---------- >> From: Burlen Loring <[email protected]> >> Date: Tue, Mar 24, 2009 at 2:55 PM >> Subject: Re: [ParaView3-Developer] Fwd: [Paraview] [Still having >> Problems] Re: Generating a distribution of ParaView with Plugin >> To: Berk Geveci <[email protected]> >> Cc: ParaQ Developers <[email protected]> >> >> >> Rafael, >> >> I am going to assume that, you have all the compiler version/qt >> version stuff sorted out, if you don't what I suggest won't make a >> difference. >> >> I recall having a similar issue. To work around I had to add my >> plugin's bin directory (where it and all of its .dll dependencies >> reside) to the PATH. When you load a dll on windows *all* of its >> dependencies must be found, either in the applications run directory >> (in this case that's the ParaView.exe location) or in the PATH. This >> all has to do with the way Windows resolves shared library >> dependencies. Your plugin won't work unless all of the dependencies >> are in the PATH or the same folder as ParaView.exe. In the 3.6 release >> we are adding the plugin's bin directory to the search space >> during/prior plugin load behind the scenes to get around these type of >> issues. >> >> There is a free dependency walker tool that is useful to determine if >> there are any dependencies that you don't know of that may be causing >> your issues. >> >> Burlen >> > > I encountered a similar issue to this when working on the Avogadro > Windows build. There is an alternate solution to this problem - if you > disable manifests for plugins then they do not need to resolve their > dependencies. The solution I found for Avogadro was to add this to our > CMakeLists.txt, > > if (MSVC) > set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /MANIFEST:NO") > endif(MSVC) > > As our plugins are built as modules this worked perfectly, Avogadro can > load its Qt based plugins from directories that do not contain > additional DLLs and we do not need to modify the environment. All > reports from users indicate that this approach works well. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the ParaView Wiki at: > http://paraview.org/Wiki/ParaView > > Follow this link to subscribe/unsubscribe: > http://www.paraview.org/mailman/listinfo/paraview > _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
