Hi Alan
>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.
yes that was what happened.
In the end the missing files are detected, but I was under the impression
that the cmake
step would detect the missing files when I assumed they were there,
therefore my original report
(where I was thinking the files existed, it was only after sending the first
report that I noticed they did not exist).
all good then
-Pedro
----- Original Message -----
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
To: "Pedro Vicente" <pedro.vice...@space-research.org>
Cc: "PLplot development list" <plplot-devel@lists.sourceforge.net>
Sent: Sunday, December 18, 2016 2:28 AM
Subject: Re: [Plplot-devel] Cmake generation with wxWidgets on Windows
> 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
