Hi Phil,
I have seen the 0-sized driver info files too, but they were always caused by
the test-driver-info program not being able to load. By extending the path with
the dll-directory that the DLLs will put into _before_ starting the build that
problem was resolved. However, I do not know how to conveniently do that in
combination with Visual Studio. You may have to set it explicitly via the
"advanced system settings", which makes the setting global and persistent.
Regards,
Arjen
> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Tuesday, September 23, 2014 3:59 AM
> To: Phil Rosenberg
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] tcl build problem
>
> On 2014-09-22 22:58+0100 Phil Rosenberg wrote:
>
> > Hi Alan
>
> > [...]I have located the DLLs on the
> lib directory and added their directory to my path, but still they don't seem
> to be
> loading.
>
> Hi Phil (taking this conversation back to the list):
>
> You need access to all the dll's in the build tree, not just a subset of them.
>
> Your words above imply dll's are _not_ being automatically located by your
> CMake
> generator in the dll subdirectory of the build tree. This has never happened
> before
> with Windows platforms that I am aware of, and ignoring our setting of the
> LIBRARY_OUTPUT_PATH variable could be an issue with either your visual studio
> generator or else CMake-3.x itself (remember our build system is currently not
> debugged throughly for that version compared to all the testing it has
> received for
> CMake-2.8.x).
>
> We set LIBRARY_OUTPUT_PATH using the
>
> set(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll)
>
> command in the top-level CMakeLists.txt file just for the Windows case. That
> variable is an extreme example of a legacy variable (probably going back to
> CMake-
> 2.0), and if it doesn't work for either of the two above situations, I am
> sure the advice
> we will be given by CMake devels is to use the modern counterparts of that
> variable
> instead which are some combination of setting the variables
> CMAKE_ARCHIVE_OUTPUT_DIRECTORY,
> CMAKE_LIBRARY_OUTPUT_DIRECTORY, and/or
> CMAKE_RUNTIME_OUTPUT_DIRECTORY.
>
> Here is the relevant background documentation (which you can find yourself by
> running "cmake --help-full") for those modern counterparts for those three
> different
> variables.
>
> "There are three kinds of target files that may be built: archive, library,
> and runtime.
> Executables are always treated as runtime targets. Static libraries are
> always
> treated as archive targets.
> Module libraries are always treated as library targets. For non-DLL
> platforms shared
> libraries are treated as library targets. For DLL platforms the DLL part of
> a shared
> library is treated as a runtime target and the corresponding import library
> is treated
> as an archive target. All Windows-based systems including Cygwin are DLL
> platforms."
>
> So on Cygwin or Windows it looks like shared library dll's (created for all
> our shared
> libraries) are treated as a "runtime" target and our device driver dll's
> (built as
> MODULE libraries) are treated as a "library" target. (That last makes no
> sense to me.
> Why wouldn't MODULE libraries which are exactly dll's be treated the same as
> library
> dll's? Of course, that may simply be incorrect background documentation
> above, but
> that is what that documentation says.)
>
> So in case that documenation is incorrect, try removing
>
> set(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll)
>
> and replacing it by
>
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY
> ${CMAKE_CURRENT_BINARY_DIR}/dll)
>
> According to the documentation the net effect of setting that variable should
> be to
> collect all executables and the dll part of shared libraries into that dll
> directory, but it
> also makes sense to me it will collect the device driver dll's (built as
> modules) as well
> in that directory. But if the build location for the device drivers is not
> moved from
> drivers to dll by the above change, then try
>
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY
> ${CMAKE_CURRENT_BINARY_DIR}/dll)
> set(CMAKE_LIBRARY_OUTPUT_DIRECTORY
> ${CMAKE_CURRENT_BINARY_DIR}/dll)
>
> instead which should work according to the documentation.
>
> And if setting one or both those variables works for you, please go ahead and
> commit the change so that Arjen can test it for his Windows platforms as well
> (which
> should also work according to the documentation of those variables).
>
> If no combination of setting either/both CMAKE_RUNTIME_OUTPUT_DIRECTORY
> or CMAKE_LIBRARY_OUTPUT_DIRECTORY locates the library and device driver
> dll's in the dll subdirectory, then we can only conclude that either the
> CMake version
> you are using or the generator you are using has a bug with regard to
> honoring the
> settings of CMAKE_RUNTIME_OUTPUT_DIRECTORY and
> CMAKE_LIBRARY_OUTPUT_DIRECTORY. Some additional tests by you with
> cmake-2.8.12.2 and the nmake generator would be required to sort out which,
> but
> hopefully, it will not come to that, and setting one or both the above
> variables will
> work for you.
>
> 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); the Time Ephemerides project
> (timeephem.sf.net);
> PLplot scientific plotting software package (plplot.sf.net); 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
> __________________________
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI
> DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-
> Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0
> Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
