Menu
▾
▴
plplot-devel
|
From: Alan W. I. <ir...@be...> - 2016-12-28 01:42:38
|
On 2016-12-27 23:41-0000 p.d...@gm... 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 __________________________ |
|
From: <p.d...@gm...> - 2016-12-28 09:14:42
|
Hi Alan Sorry for top posting, but I’m on my phone which doesn't seem to indent older text so I think this is simpler. A common scenario for me (I thought this may have been Laurent’s issue, but it seems not) is that I make a change in the wxWidgets part of plplot, then in visual studio I right click an example and select run. This triggers plplot to rebuild (in visual studio static builds all the devices are built into a single plplot library) and the example builds and runs. I hit the appropriate number to select wxWidgets and I find my change has made no different. I try a few more things and find nothing helps. Then I realise that wxPLViewer hasn't been rebuilding and was built with code before my changes. So I right click that project, hit build, test my changes, probably revert some changes and get back to my original change. Rebuilding wxPLViewer manually as I go. Mostly now I remember to do the manual build. But occasionally I forget and it often takes me ages to realise the problem. The deal is that although there is no build time dependency of the examples upon wxPLViewer, there is a run time dependency. Does that make sense? Phil Sent from my Windows 10 phone From: Alan W. Irwin Sent: 28 December 2016 01:42 To: Phil Rosenberg; Pedro Vicente; Laurent Berger; PLplot development list Subject: wxwidgets-related dependencies On 2016-12-27 23:41-0000 p.d...@gm... 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2016-12-28 19:08:34
|
On 2016-12-28 09:14-0000 p.d...@gm... wrote: > The deal is that although there is no build time dependency of the examples upon wxPLViewer, there is a run time dependency. Does that make sense? Yes. As a matter of convenience you would like _all_ your changes to build rather than the subset of them you get now when you build just an example. To get that effect I strongly recommend you build the "all" target. After all, that is exactly what that convenience target is for. Anyhow, please try the "all" target as a means of satisfying your needs. N.B. that target actually only builds the targets that are necessary for installation (e.g., it skips all the Unix-only custom test targets that would fail for you). So that target is not to be confused with another target that apparently exists with Visual Studio. I have forgotten its name but it ends up attempting to build _every_ target including all the custom ones which, of course, always fails for the bare windows case. 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 __________________________ |
|
From: <p.d...@gm...> - 2016-12-28 19:14:22
|
Hi Alan The problem with building all is that it rebuilds all the examples. When using static libs this means relinking them as well and the whole process takes a few minutes, rather than the few seconds to build one example. Phil Sent from my Windows 10 phone From: Alan W. Irwin Sent: 28 December 2016 19:08 To: p.d...@gm... Cc: Pedro Vicente; Laurent Berger; PLplot development list Subject: RE: wxwidgets-related dependencies On 2016-12-28 09:14-0000 p.d...@gm... wrote: > The deal is that although there is no build time dependency of the examples upon wxPLViewer, there is a run time dependency. Does that make sense? Yes. As a matter of convenience you would like _all_ your changes to build rather than the subset of them you get now when you build just an example. To get that effect I strongly recommend you build the "all" target. After all, that is exactly what that convenience target is for. Anyhow, please try the "all" target as a means of satisfying your needs. N.B. that target actually only builds the targets that are necessary for installation (e.g., it skips all the Unix-only custom test targets that would fail for you). So that target is not to be confused with another target that apparently exists with Visual Studio. I have forgotten its name but it ends up attempting to build _every_ target including all the custom ones which, of course, always fails for the bare windows case. 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2016-12-29 00:26:27
|
On 2016-12-28 19:14-0000 p.d...@gm... wrote: > Hi Alan > The problem with building all is that it rebuilds all the examples. When using static libs this means relinking them as well and the whole process takes a few minutes, rather than the few seconds to build one example. I agree "a few minutes" is clearly not acceptable in a development environment where you don't want to wait that long before you try your next code changes. (I can whittle that down to 5 seconds here for the shared library + dynamic devices case if I use the options -DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON -DENABLE_wxwidgets=ON, but you might not be able to do that well there for the static case and with your different compiler and linker, and in any case even 5 seconds is a bit much). Therefore, to deal with your special testing needs, I would be willing to define a bunch of custom test targets called test_x00c_wxPLViewer,..., test_x33c_wxPLViewer which depended on wxwidgets, wxPLViewer and the relevant C standard example and which would run, e.g., examples/c/x00c -dev wxwidgets For the "00" case, and similarly for the rest of our standard examples. The above command has been expressed in Linux terms, but CMake allows you to run that command in a way that should work on all platforms. So the end result should be you would click on one of test_x00c_wxPLViewer,..., test_x33c_wxPLViewer buttons in your IDE, all prerequisites would be rebuilt, and the relevant example would be run with -dev wxwidgets. If that idea would work for you, let me know, and I will put it on my post-release ToDo list. 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 __________________________ |
|
From: <p.d...@gm...> - 2016-12-29 08:47:36
|
Hi Alan I'm not sure if that would work. If I execute (I.e. Run or debug) that project, would it run the example? Sent from my Windows 10 phone From: Alan W. Irwin Sent: 29 December 2016 00:26 To: Phil Rosenberg; Pedro Vicente; Laurent Berger; PLplot development list Subject: RE: wxwidgets-related dependencies On 2016-12-28 19:14-0000 p.d...@gm... wrote: > Hi Alan > The problem with building all is that it rebuilds all the examples. When using static libs this means relinking them as well and the whole process takes a few minutes, rather than the few seconds to build one example. I agree "a few minutes" is clearly not acceptable in a development environment where you don't want to wait that long before you try your next code changes. (I can whittle that down to 5 seconds here for the shared library + dynamic devices case if I use the options -DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON -DENABLE_wxwidgets=ON, but you might not be able to do that well there for the static case and with your different compiler and linker, and in any case even 5 seconds is a bit much). Therefore, to deal with your special testing needs, I would be willing to define a bunch of custom test targets called test_x00c_wxPLViewer,..., test_x33c_wxPLViewer which depended on wxwidgets, wxPLViewer and the relevant C standard example and which would run, e.g., examples/c/x00c -dev wxwidgets For the "00" case, and similarly for the rest of our standard examples. The above command has been expressed in Linux terms, but CMake allows you to run that command in a way that should work on all platforms. So the end result should be you would click on one of test_x00c_wxPLViewer,..., test_x33c_wxPLViewer buttons in your IDE, all prerequisites would be rebuilt, and the relevant example would be run with -dev wxwidgets. If that idea would work for you, let me know, and I will put it on my post-release ToDo list. 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 __________________________ |
|
From: Alan W. I. <ir...@be...> - 2016-12-29 18:30:10
|
On 2016-12-29 08:47-0000 p.d...@gm... wrote: > Hi Alan > I'm not sure if that [test_x00c_wxPLViewer, etc. targets] would work. If I execute (I.e. Run or debug) that project, would it run the example? Hi Phil: If the custom target has no associated COMMAND, what should happen is instead of clicking on the all button to rebuild everything, you would be clicking on the test_x00c_wxPLViewer, etc., buttons to rebuild just the subset of the project that you need. In other words, that should completely satisfy the limited rebuild need you expressed. However, there is a bigger possibility here as well which is to use COMMAND see <https://cmake.org/cmake/help/latest/command/add_custom_target.html> to actually execute the example appropriately after the rebuilds when you click on test_x00c_wxPLViewer, etc. I can guarantee this approach (building all prerequisites then running the appropriate C standard example using -dev wxwidgets) will work on the command line with Unix shell and make when you build one of the test_x00c_wxPLViewer, etc. targets, and I am virtually positive it will also work with Windows CMD and nmake as well. But we don't really know whether that bigger possibility would work with your particular IDE until we try it. So after the release when we both will have more time for this, we should do some joint experiments both with nmake and your IDE to figure out what is most useful to you and other Windows developers/testers. 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 __________________________ |
|
From: <p.d...@gm...> - 2016-12-29 18:46:04
|
Hi Alan I don't know enough about cmake and how it creates visual studio projects/solutions to know what will work. All I know is that cmake generates a visual studio solution, which when opened in visual studio contains multiple projects, one for each target (library and executable) and some others for executing other commands or bulk builds such as ALL and INSTALL. I can right click any of these and hit build, to build just that project. Or for the executable ones I can right click them and hit debug to run them in the debugger. If I right click a library project and hit debug then I just get an error. From memory there is a property like “debug target” that must be set and I think for executables it defaults to the build target, whereas for libraries it is blank. Just setting a command to execute at the end of a build wouldn't do the job as it wouldn't run in the debugger, which is often the aim. I'm not sure what is so bad about setting the viewer as a dependency of the examples? Anyway, you know the issue and you know cmake way better than me so just go for it and we can see how it works. Phil Sent from my Windows 10 phone From: Alan W. Irwin Sent: 29 December 2016 18:30 To: Phil Rosenberg; Pedro Vicente; Laurent Berger; PLplot development list Subject: RE: wxwidgets-related dependencies On 2016-12-29 08:47-0000 p.d...@gm... wrote: > Hi Alan > I'm not sure if that [test_x00c_wxPLViewer, etc. targets] would work. If I execute (I.e. Run or debug) that project, would it run the example? Hi Phil: If the custom target has no associated COMMAND, what should happen is instead of clicking on the all button to rebuild everything, you would be clicking on the test_x00c_wxPLViewer, etc., buttons to rebuild just the subset of the project that you need. In other words, that should completely satisfy the limited rebuild need you expressed. However, there is a bigger possibility here as well which is to use COMMAND see <https://cmake.org/cmake/help/latest/command/add_custom_target.html> to actually execute the example appropriately after the rebuilds when you click on test_x00c_wxPLViewer, etc. I can guarantee this approach (building all prerequisites then running the appropriate C standard example using -dev wxwidgets) will work on the command line with Unix shell and make when you build one of the test_x00c_wxPLViewer, etc. targets, and I am virtually positive it will also work with Windows CMD and nmake as well. But we don't really know whether that bigger possibility would work with your particular IDE until we try it. So after the release when we both will have more time for this, we should do some joint experiments both with nmake and your IDE to figure out what is most useful to you and other Windows developers/testers. 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 __________________________ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X