On Fri, Mar 13, 2015 at 05:19:02PM -0700, Alan Irwin wrote: > On 2015-03-13 10:26-0700 Alan W. Irwin wrote: > >On 2015-03-13 10:19-0000 Andrew Ross wrote: > >>2) The libharu build succeeds, but the hpdf_pdfa.h include file is not > >>installed so the plplot build of the pdf driver fails. > > Hi Andrew: > > As of commit fac174e I have changed the CMake-based libharu build > system to install both hpdf_namedict.h and hpdf_pdfa.h because both > those headers are installed by the autotools-based libharu build > system. As far as I can tell, my own epa_build should have complained > about missing hpdf_pdfa.h, but for some unknown reason it didn't. But > in any case, thanks for reporting this issue which has now been fixed. > > I also took this opportunity to search the -dev pdf results for > rendering issues, and I have documented everything I spotted at > <https://sourceforge.net/p/plplot/bugs/155/>. I think all of these I > have seen before so I conclude they are not due to any recent changes. > In agreement with that conclusion, note that most devices do not share > these rendering issues so they cannot be due to recent plbuf changes > (which typically clobber every device result). So this comprehensive > check of the rendering for all our examples has been most reassuring > from the release quality perspective.
Thanks Alan. I suspect you also had the Debian packages installed? The header would be picked up from there, even if you were linking against the epa_build version. Providing the versions weren't too out of sync it wouldn't be problematic and there would be no way of telling. This is one advantage of the pbuilder approach. Each time you start with a pristine base install and only install additional packages which are explicitly requested. > @ Andrew: I think this concludes all release topics that we have discussed > previously, but if there is anything else we have discussed that I > have forgotten or you notice any new release-related topic, please let > me know. I agree. There is the outstanding octave segfault which occurs with one of the p?? examples when run explicitly, but not with the test scripts. This is odd, but probably not release critical. I may still get chance to track this down, but debugging such issues with octave is tricky since you can't easily use gdb. I can't see what the difference is between the two cases, but this at least provides a starting point. Otherwise it is the documented issues with the various drivers, but these are longstanding in most cases. A good goal for the next release cycle would be to try and squash as many of these as we can to get more uniform behaviour between all (or at least our main) drivers. Andrew ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
