From: Rafael L. <rla...@us...> - 2005-05-04 20:44:06
|
* Rafael Laboissiere <rla...@us...> [2005-05-03 23:03]: > I will make the final compatibility test with the pdl package in Debian > testing, as soon as I get HEAD to compile again (gcw is temporarily > broken). It is done. I could generate Debian packages for HEAD which are compatible with the pdl packages currently in testing (sarge). I think that this is a good check for backward compatibility. Also, the gcw driver works like a charm. Tom, regarding the backward compatibility issues, I think the way is clear for release 5.5.3. -- Rafael |
From: <mj...@ga...> - 2005-05-04 20:57:19
|
Rafael Laboissiere writes: > * Rafael Laboissiere <rla...@us...> [2005-05-03 23:03]: > > > I will make the final compatibility test with the pdl package in Debian > > testing, as soon as I get HEAD to compile again (gcw is temporarily > > broken). > > It is done. I could generate Debian packages for HEAD which are > compatible with the pdl packages currently in testing (sarge). I think > that this is a good check for backward compatibility. Also, the gcw > driver works like a charm. Tom, regarding the backward compatibility > issues, I think the way is clear for release 5.5.3. I mentioned wanting to do some compatibility testing myself, but am unable to find the time to reactivate some of my old code & do a controlled test. So AFAIAC, the pdl test is good enough for now. If any issues turn up later, we can address them in a subsequent fix. -- Maurice LeBrun mj...@ga... |
From: Alan W. I. <ir...@be...> - 2005-05-05 01:14:28
|
On 2005-05-04 22:43+0200 Rafael Laboissiere wrote: > * Rafael Laboissiere <rla...@us...> [2005-05-03 23:03]: > >> I will make the final compatibility test with the pdl package in Debian >> testing, as soon as I get HEAD to compile again (gcw is temporarily >> broken). > > It is done. I could generate Debian packages for HEAD which are > compatible with the pdl packages currently in testing (sarge). I think > that this is a good check for backward compatibility. Also, the gcw > driver works like a charm. Tom, regarding the backward compatibility > issues, I think the way is clear for release 5.5.3. But not quite in other respects. gcw still has static device build issues I would like to fix, but I cannot do that until this round of gcw changes (including a change to the library location) are finalized. Otherwise, I agree 5.5.3 seems pretty much ready to be released. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 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); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2005-05-05 18:12:38
|
* Alan W. Irwin <ir...@be...> [2005-05-04 18:14]: > But not quite in other respects. gcw still has static device build issues I > would like to fix, I already notice that the follwoing is broken: $ ./configure --enable-gcw --disable-dyndrivers $ make [...] make[2]: *** No rule to make target `gcw.lo', needed by `libplplotdrv.la'. Is this the issue you are referring to? If yes, how do you think you can fix it? -- Rafael |
From: Alan W. I. <ir...@be...> - 2005-05-05 18:49:07
|
On 2005-05-05 19:59+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2005-05-04 18:14]: > >> But not quite in other respects. gcw still has static device build issues I >> would like to fix, > > I already notice that the follwoing is broken: > > $ ./configure --enable-gcw --disable-dyndrivers > $ make > [...] > make[2]: *** No rule to make target `gcw.lo', needed by `libplplotdrv.la'. > > Is this the issue you are referring to? Probably. (I was virtually positive it would break somewhere since the static device case hadn't been worked on since the separation of the library code for the gnome toolkit from the gcw device code.) > If yes, how do you think you > can fix it? For the static device case the linking issues for the code in libplplotgnome2 are similar to the linking issues for the code in libplplottcltk so when I fix this, I intend to follow the previously established pattern for that latter code. But first we need a decision about the location of the source code for libplplotgnome2. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 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); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2005-05-05 19:22:56
|
* Alan W. Irwin <ir...@be...> [2005-05-05 11:49]: > For the static device case the linking issues for the code in > libplplotgnome2 are similar to the linking issues for the code in > libplplottcltk so when I fix this, I intend to follow the previously > established pattern for that latter code. Related to the gcw driver, there is a more subtle problem regarding the STATIC_DRIVERS variable. This variable is a list of *.lo objects to be built when dyndrivers is disabled. The code in drivers/Makefile assumes that there is a *.c file for each *.lo listed. Since Tom changed gcw.c to gcw-driver.c, then we get the error I mentioned before: > On 2005-05-05 19:59+0200 Rafael Laboissiere wrote: > > >I already notice that the following is broken: > > > > $ ./configure --enable-gcw --disable-dyndrivers > > $ make > > [...] > > make[2]: *** No rule to make target `gcw.lo', needed by > > `libplplotdrv.la'. Renaming gcw-driver.c back to gcw.c will fix the problem, trivially. Otherwise, I am afraid there will be no simple fix. What do you think, Tom? -- Rafael |