Re: [Plplot-devel] [Plplot-general] MinGW Make Trouble

[Alan W. I. <ir...@be...>]

On 2010-02-10 20:39+0100 Werner Smekal wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
>>
>> Werner, your combined knowledge of windows and CMake makes you the obvious
>> candidate to ask Windows-related questions in an informed way on the CMake
>> list. Therefore, would you please ask on that list whether there is a way
>> for cmake to set up Windows builds to allow dll's to be found or is it a
>> necessity to externally set the PATH?
>
> If a executable is run and a dll is needed, Windows looks first in the
> current directory for the dll. Then in the PATH. Then in
> c:\windows\system32 (and in some other system directories. Maybe PATH
> comes later, but this doesn't matter). Since we don't want to copy the
> dlls multiple times, our only chance is to change the PATH environment
> variable. I just read the cmake documentation about setting environment
> variables
> (http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:set) and it
> should be possible to change the PATH variable that way. Presumably only
> as long as the Terminal window is open (so at least for the cmake
> configure stage). If you close the terminal, start it again this change
> is surely gone and I assume, if you then compile plplot (which is
> already configured) PATH won't be changed again, so you run into
> problems again. So this is no solution.

I think you must be right.  This is the issue (environment variable
set in cmake not available for build) that I referred to based on
my Linux experience with environment variables.

>
> Actually there are two problems.
>
> 1) plplot build is not finished, since testing the rc files fails, due
> to the "missing" dlls. I would suggest that for windows we force that
> the test-drv-info executable will be built into the dll folder (where
> for windows all dlls are gathered). Therefore the build gets through
> (since the dlls are in the same folder than test-drv-info).

Please go ahead with that.

>
> 2) The examples don't run, since the dlls are not found. Now you need to
> either set the PATH variable or copy the dlls. User interaction is
> needed, the dlls are in the dll directory and the examples are in the
> examples directory, and this shouldn't be changed. So IMO the best we
> can do is, that in summary.cmake we add at the end a message (with many
> !!!!!) if it's a shared build on Windows and examples are built as well,
> the user is asked to add the dll directory to the PATH variable.

Please go ahead with that.  Also, please implement a similar message for the
new CMake-based build system for the installed examples.  See the summary
message at the end of examples/CMakeLists.txt.

>
> I believe the most Windows developers know about what to do, if they run
> a program and a message box pops up telling him that the dll is missing.
>
> Still not perfect, but on the other hand it's not possible to cover
> everything. If the user wants to compile his own executables, he *must*
> take care of the dlls anyway. So if he doesn't RTFM it's best he gets
> into trouble trying to run the examples already. It would be more
> confusing if the examples run and his own programs not.

Agreed.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________