[Paraview] Fwd: [ParaView3-Developer] Fwd: [Still having Problems] Re: Generating a distribution of ParaView with Plugin

[Mike Jackson]

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 Jackson


On Tue, Mar 24, 2009 at 5:06 PM, Marcus D. Hanwell <marcus at cryos.org> wrote:
> Berk Geveci wrote:
>> Forwading from developers list.
>>
>>
>> ---------- Forwarded message ----------
>> From: Burlen Loring <burlen.loring at kitware.com>
>> 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 <berk.geveci at kitware.com>
>> Cc: ParaQ Developers <ParaQ-Developer at paraview.org>
>>
>>
>> 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
>