On 2016-12-17 19:25-0500 Pedro Vicente wrote:
>
> Hi Alan
>
>> (3) Static PLplot libraries + device driver code embedded in our core
>> static library (identified by its "plplot" basename).
>
> I always use (3).
>
> I repeated what I had done before:
>
> My wxwidgets libraries are located at
>
> M:\wx\wxwidgets-3.1.0\lib\vc_lib
>
> here there are several .lib files like this one
>
> wxmsw31ud_core.lib
>
> 1) I deleted all .lib files from that location
> 2) did a PLplot cmake run with
>
> cmake ".." -G "Visual Studio 14" -DPL_DOUBLE:BOOL=ON -DBUILD_TEST:BOOL=ON
> -DCMAKE_CONFIGURATION_TYPES:STRING="Debug" -DCMAKE_BUILD_TYPE:STRING="Debug"
> -DBUILD_SHARED_LIBS:BOOL=OFF -DSTATIC_RUNTIME:BOOL=ON -DPLD_wxwidgets:BOOL=ON
> -DwxWidgets_ROOT_DIR:PATH=%WXWIN% -DwxWidgets_LIB_DIR:PATH=%WXWIN%\lib\vc_lib
> -DwxWidgets_CONFIGURATION=mswud -DwxWidgets_EXCLUDE_COMMON_LIBRARIES:BOOL=OFF
>> cmake.out.txt 2>&1
>
> where
> %WXWIN%
> is
> M:\wx\wxwidgets-3.1.0
>
> cmake.out.txt is attached and it detected wxwidgets
>
> 2) Built the Visual Studio generated solution and got the wxwidgets linking
> errors
>
> 4) rebuilt wxwidgets libraries at M:\wx\wxwidgets-3.1.0\lib\vc_lib
>
> 5) did the same PLplot cmake run
>
> 6) Built the Visual Studio generated solution , no errors
Hi Pedro:
Am I understanding your test properly? You clobbered your wxwidgets
installation (by removing the .lib files), our build system did not
detect those removed .lib files, but Visual Studio did in step 2. You
fixed that wxwidgets installation issue, ran cmake again, and this
time Visual Studio worked. Isn't this exactly how you would like
our build system to work in conjunction with Visual Studio?
My point is CMake find commands only look for a certain tiny subset of a given
installation, and if you haven't clobbered anything in that subset it won't
detect
anything wrong. But of course when you try and build and run with
Visual Studio, the missing .lib files were detected.
Anyhow, I don't see anything wrong here. Am I missing something?
>
> I took a look at the PLplot
> FindwxWidgets.cmake
> module and it seems that there is an attempt to find the wxwidgets libraries
> (the actual file names), here
>
> find_library(WX_${LIB}${_DBG}
> NAMES
> wxbase31${_UCD}${_DBG}_${LIB}
>
>
> so, not sure exactly what happened, and probably we could leave this possible
> non-critical bug for after the release (if it's a bug).
As far as I can tell from the above argument it is not a bug. But if it
turns out to be a bug, I will likely wait to fix it until post-release
because it doesn't seem to be release critical (if a bug at all).
>
> I started using cmake in my projects some months ago, and what I do to detect
> libraries is like this,
> an example for the JSON jansson library:
>
>
> find_library(JANSSON_LIBRARY NAMES jansson HINTS
> "/data/data127/pvicente/install/jansson-2.9/lib/")
> if(NOT JANSSON_LIBRARY)
> message(FATAL_ERROR "jansson library not found")
> else()
> message("-- Found jansson library at: " ${JANSSON_LIBRARY})
> endif()
Good.
[....]
> Here's my Windows call (the path like /C/ is because this is in Git Bash)
>
> cmake .. -DSTATIC_CRT:BOOL=ON -DJANSSON_INCLUDE:PATH=/C/include
> -DJANSSON_LIBRARY=/C/lib/jansson.lib
>
>
> my library file is actually called (extra _d)
> /C/lib/jansson_d.lib
>
> and cmake said
>
> -- Found jansson.h header file at: C:/include
> -- Found jansson library at: C:/lib/jansson.lib
find_library (in fact, all the CMake find technology) is a no-op if
you specify the answer it is trying to determine (JANSSON_LIBRARY).
So if your specification (-DJANSSON_LIBRARY=/C/lib/jansson.lib)
points to a file that doesn't exist, CMake will happily accept that
and move on. However, if you don't specify, CMake find technology
will only find existing files.
>
> then when I build Visual Studio I get
>
> LINK : fatal error LNK1104: cannot open file 'C:\lib\jansson.lib'
>
> my understanding is that
> find_library
>
> does not actually detect if the argument is an existent file
That depends, see above.
>
> Or could be that it does not because I am using the same variable name
> JANSSON_LIBRARY
> for both the argument of
> cmake .. -DJANSSON_LIBRARY
> and
> find_library(JANSSON_LIBRARY
>
> so , this print
> -- Found jansson library at: C:/lib/jansson.lib
>
> is not actually true for this example.
Exactly. You have specified what find_library was trying to
determine, and the CMake find technology is designed following the
philosophy that the customer must always be right. :-)
So it is better if you tell CMake as little as possible with
command-line options in case you make some mistake with those as
in the above example. Also, try
cmake --help-full |less
to look at complete documentation of cmake. So within
that less command you can look for the regexp "find_library$", and
there you will find (heh) everything you need to know
about that command and how to influence its results (e.g.,
by specifying CMAKE_LIBRARY_PATH) without telling it
something that turns out to be incorrect such as in your
example above.
The above is what I routinely do on the command line on Linux to
access CMake documentation. Let's face it, "less" is a simple but
wonderful app that does a limited job well. A perfect example, of the
Unix philosopy. So this method should work on any Unix system or
Unix-like Windows system (e.g., Cygwin or MinGW-w64/MSYS2). But if
you don't have Unix tools like "less" at hand, you can also instantly
get complete documentation for find_library from a google search, and
by playing with the URL in an obvious way you can get any version of
the find_library documentation from 3.0.x to 3.7.x in case there were
any changes during that range of releases.
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
__________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
