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
