On 2014-11-13 07:31-0000 Arjen Markus wrote: >>> [...] >> the output is the result from the _second_ pass with make (the first fails >> as nm can >> not find >> "<build-directory>/src/libplplot.so") >> >> This build issue still continues to completely puzzle me. I don't confirm >> that issue on >> my platform, and I can see nothing wrong with the CMake code that enforces >> the >> constraint that the plplot library MUST be built before the nm command is >> executed. >> But obviously from your and Phil's experience there is still something >> problematic >> with the CMake dependency logic (or maybe even a Cygwin CMake bug?) which >> allows nm to be run before the library is built so you are forced to use >> that double >> build workaround to get around it. So the only advice I can give you is >> continue to >> use that workaround, but this is not very satisfying since I completely >> dislike >> "computer magic" like this. >> >
> What I noticed is that it is complaining about a shared object in the src subdirectory. On Cygwin as well as MinGW/MSYS and bare Windows this file is built in the dll subdirectory. Could that be an indication of what is going wrong? Good catch! I should have seen that issue immediately in the CMake logic, but my eyes glided right over the problem area (where <build_tree>/src/libplplot.so was used for the name of the library which is wrong on Cygwin both in PATH and name). Please try commit 405544f which should solve this issue on the assumption that the generator expression $<TARGET_LINKER_NAME:plplot> will find the correct full path of the plplot library on all platforms. This generator expression works on Linux, and I am guessing it will work on Cygwin with the dll subdirectory location, but if it doesn't work (i.e., if you still need the double build), then please look at "cmake --help-full" results to look for alternative generator expressions that might work, and experiment with doc/docbook/src/CMakeLists.txt until you get the right one. Once this generator expression works, then it will generate a non-empty symbols file which will be used in the documentation. But what was going on before was an empty file of symbols was being used on Cygwin on the second build which implies the programme listing in section 21.1 right after "The formal definition of the PLplot C API is everything that is defined in the include file plplot.h. This includes all the function prototypes, the defined structures and the semantics of the constants. The list of symbols currently exported by the shared library libplplot.h that are declared in plplot.h is the following:" would be empty before the fix, but now it should have 3 long columns of PLplot symbols in a programme listing. This difference may also explain the different number of pages you observed for your previous case compared to the Linux result. 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 __________________________ ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
