On 2016-12-27 23:41-0000 p.d.rosenb...@gmail.com wrote: > Hi Laurent > I know you have said you have cleaned and you have rebuilt. However, there > may be a build tree dependency issue catching us out. Can you ensure you > specifically rebuild the wxPlviewer project by right clicking it and > selecting build in visual studio? If you just right click an example and > click build or debug then this project doesn't get built/rebuilt. This means > in a previously used build tree you may be using a stale wxplviewer > executable or in a fresh tree you may end up using the wxplviewer from your > last build of the INSTALL project as a local version may not be found. >
> Alan – I have mentioned this before. What is needed is for all examples to depend upon the wxPLViewer executable, which in turn depends upon plplot and the wxWidgets driver, so that if changes are made to plplot or the driver then building of an example triggers a rebuild of wxPLViewer. Hi Phil: You definitely do not want any of our standard examples to depend on wxPLViewer. Because the two are normally completely unrelated. Of course, the test_c_wxwidgets target is a completely different story since it specifically runs a subset of our C examples with -dev wxwidgets so that target currently depends on the wxPLViewer target, i.e., when test_c_wxwidgets is built, an attempt is always made to build wxPLViewer first. (Of course, nothing is done if wxPLViewer is completely up to date, i.e, all its own direct and indirect dependencies, e.g., the plplot, plplotcxx, and plplotwxwidgets libraries are already built and it is already built.) So shouldn't that chain of dependencies already satisfy your dependency needs? That is, the current situation is if code in any of the plplot, plplotcxx, or plplotwxwidgets libraries is changed, then an attempt to rebuild test_c_wxwidgets will attempt to rebuild the particular library dependency with changed code and relink wxPLViewer against the changed set of libraries. A small complication for this dependency chain exists for the case of shared libraries + dynamic devices (the only case where the wxwidgets target exists because for only this case the wxwidgets device driver code is built into an independent dll rather than being embedded in the plplot library). But here also you are covered because for this case the test_c_wxwidgets depends on the wxwidgets target. So any change in the (for this case independent) wxwidgets device driver code will result in a rebuild of wxwidgets. That code does not link in any way to wxPLViewer so I don't see any reason to rebuild wxPLViewer if the wxwidgets device driver code is changed and rebuilt. Of course, wxPLViewer will get rebuilt if its common code with the wxwidgets device driver, drivers/wxwidgets_comms.cpp, gets changed. So I think we have it completely covered, but if you see any flaw in my argument above that leads to that conclusion, please let me know. 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
