From: Werner S. <sm...@ia...> - 2006-10-27 20:08:01
|
Hi all, sorry for the lot of cvs commits ;). I made a lot of changes regarding the dll problematic, since Arjen told me about the problem, that if a dll is compiled which uses another dll a MAKINGDLL will make trouble since you use and make a dll at the same time. The solution is to make these macro definitions more "granular". Nearly any dll has now it's own macros MAKING??DLL and USING??DLL and everything can be fine tuned now, e.g. the plplot library is now be built with -DMAKINGPLDLL -DUSINGNNDLL -DUSINGCSADLL. Also csa library is now own its again, i.e. doesn't use any header file from plplot any more. So for other dlls copy pldll.h to a proper directory an rename the PL to something different. I also made some changes to the nn library, it also exports now some functions to a dll and nan.h has now the same definitions as nan.h from the csa library. This completes now the qhull support for visual c++. Everything tested on windows, but Linux shouldn't be affected actually. Regards, Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Werner S. <sm...@ia...> - 2006-10-28 15:00:53
|
Hi, I forgot to mention, that for the examples or your own programs it's much easier, only USINGDLL needs to be defined. No need to define a macro for all dlls included. Regards, Werner Werner Smekal wrote: > Hi all, > > sorry for the lot of cvs commits ;). I made a lot of changes regarding > the dll problematic, since Arjen told me about the problem, that if a > dll is compiled which uses another dll a MAKINGDLL will make trouble > since you use and make a dll at the same time. The solution is to make > these macro definitions more "granular". Nearly any dll has now it's own > macros MAKING??DLL and USING??DLL and everything can be fine tuned now, > e.g. the plplot library is now be built with -DMAKINGPLDLL -DUSINGNNDLL > -DUSINGCSADLL. Also csa library is now own its again, i.e. doesn't use > any header file from plplot any more. So for other dlls copy pldll.h to > a proper directory an rename the PL to something different. > > I also made some changes to the nn library, it also exports now some > functions to a dll and nan.h has now the same definitions as nan.h from > the csa library. This completes now the qhull support for visual c++. > > Everything tested on windows, but Linux shouldn't be affected actually. > > Regards, > Werner > -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2006-10-29 18:59:54
|
I think we should be mentally prepared for a PLplot development release in the very near future featuring our CBS. I am starting work today on one release blocker (a script and accompanying CBS changes to create a release tarball). I have been in recent contact off list with Hazen about another release blocker (Tcl/Tk on Mac OS X), and he is following a good new lead which I think will solve the issue. It appears to me from Arjen's and Werner's recent work that our CBS on windows is already well ahead of our previous windows build system and making steady improvements that should strongly encourage the use of PLplot on windows. Thus, the two issues above are the only release blockers that I know of, and I hope we can make a development release shortly after those issues are dealt with to encourage many users to try out our CBS. 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); 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: Alan W. I. <ir...@be...> - 2006-10-30 04:24:16
|
On 2006-10-29 10:57-0800 Alan W. Irwin wrote: > I am starting work today on one release blocker (a script and > accompanying CBS changes to create a release tarball). I have just finished the first part of this which is to create a custom target called prebuild_dist to pre-build "everything" required for a distribution tarball and copy it to the source tree (if the build tree is different from the source tree). The next step (tomorrow) is to collect almost everything in the source tree into a tarball using cpack. Comparisons between a tarball created this way and previous tarballs should tell me whether there is anything significant that is missing from the cpack-created tarball. The final step (hopefully also tomorrow) is to arrange with our CBS to use those generated files in the source tree if they exist (e.g., if they come as part of the distribution tarball). Note, I have deliberately excluded the SWIG-generated files from "everything" above. This means SWIG will be an extra prerequisite to build PLplot (if you want the Python and Java interfaces), but SWIG is now widely deployed in binary versions on Mac OS X (via fink) and Linux. Furthermore, binaries are available for windows from the SWIG download area. Thus, I don't think this extra prerequisite would be a significant burden to our users. If any developer here feels strongly that SWIG-generated files should be prebuilt for our future distributions then (a) it should be possible (although non-trivial) for them to implement pre-building those files, and (b) more difficult but still possible to implement a way for users to actually use those pre-built files in their CBS build. The reason why (b) is difficult is CMake uses SWIG in a rather obfuscated way deep in a macro so a lot of that logic will have to be figured out and copied for the special case when SWIG-generated files are pre-built. If nobody wants to bother with this, then that might be a good thing since it is certainly a cleaner/simpler solution to ask our users to generate those files with SWIG themselves. 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); 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: Arjen M. <arj...@wl...> - 2006-10-30 07:58:05
|
Alan W. Irwin wrote: >If any developer here feels strongly that SWIG-generated files should be >prebuilt for our future distributions then (a) it should be possible >(although non-trivial) for them to implement pre-building those files, and >(b) more difficult but still possible to implement a way for users to >actually use those pre-built files in their CBS build. The reason why (b) >is difficult is CMake uses SWIG in a rather obfuscated way deep in a macro >so a lot of that logic will have to be figured out and copied for the >special case when SWIG-generated files are pre-built. If nobody wants to >bother with this, then that might be a good thing since it is certainly a >cleaner/simpler solution to ask our users to generate those files with SWIG >themselves. > > Perhaps we should try to put effort in releasing prebuilt libraries via CPack: If users are reluctant to install SWIG on their systems, they may not like to/be able to build PLplot from source anyway. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2006-10-30 07:33:36
|
Werner Smekal wrote: >Hi all, > >sorry for the lot of cvs commits ;). I made a lot of changes regarding >the dll problematic, since Arjen told me about the problem, that if a >dll is compiled which uses another dll a MAKINGDLL will make trouble >since you use and make a dll at the same time. The solution is to make >these macro definitions more "granular". Nearly any dll has now it's own >macros MAKING??DLL and USING??DLL and everything can be fine tuned now, >e.g. the plplot library is now be built with -DMAKINGPLDLL -DUSINGNNDLL >-DUSINGCSADLL. Also csa library is now own its again, i.e. doesn't use >any header file from plplot any more. So for other dlls copy pldll.h to >a proper directory an rename the PL to something different. > >I also made some changes to the nn library, it also exports now some >functions to a dll and nan.h has now the same definitions as nan.h from >the csa library. This completes now the qhull support for visual c++. > >Everything tested on windows, but Linux shouldn't be affected actually. > > > Hi Werner, great that you have solved that issue/pity that we need to do this. I had been planning to send you a mail about - after my success with Fortran I wanted to continue with Tcl again and this issue reared its ugly head again. I am not sure I will be able to look at this this week, but I will do my best. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-10-30 08:35:27
|
Hi Arjen, > Hi Werner, > > great that you have solved that issue/pity that we need to do this. I > had been > planning to send you a mail about - after my success with Fortran I wanted > to continue with Tcl again and this issue reared its ugly head again. > > I am not sure I will be able to look at this this week, but I will do my > best. if you need help with the tcl dll let me know. It should now be straight forward to add dll support. Thanks, Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Arjen M. <arj...@wl...> - 2006-10-30 08:09:52
|
Alan W. Irwin wrote: >I think we should be mentally prepared for a PLplot development release >in the very near future featuring our CBS. > >I am starting work today on one release blocker (a script and >accompanying CBS changes to create a release tarball). > >I have been in recent contact off list with Hazen about another release >blocker (Tcl/Tk on Mac OS X), and he is following a good new lead which I >think will solve the issue. > >It appears to me from Arjen's and Werner's recent work that our CBS on >windows is already well ahead of our previous windows build system and >making steady improvements that should strongly encourage the use of PLplot >on windows. Thus, the two issues above are the only release blockers that I >know of, and I hope we can make a development release shortly after those >issues are dealt with to encourage many users to try out our CBS. > > Hi Alan, we can safely conclude that for "bare" Windows the CBS is much more powerful than the old system, though there are a few issues that require solving still. I am not quite sure about the status on Cygwin - I had some funny problems with C++ there. I should check that ASAP, I guess. One real problem is: how do we ensure we have checked the myriad of build options/environments? The notes on the Wiki are one thing, I guess, and the most systematic so far. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-10-30 08:48:25
|
Hi, > > One real problem is: how do we ensure we have checked the myriad of build > options/environments? The notes on the Wiki are one thing, I guess, and > the most > systematic so far. One possible solution is provided by kitware (the creators of cmake) called Dart ( http://public.kitware.com/Dart/HTML/Index.shtml ). It can be also integrated in cmake scripts. Question is, if it is worth the efforts to set up such a solution. Regards, Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2006-10-30 15:59:31
|
On 2006-10-30 09:47+0100 Werner Smekal wrote: > Hi, >> >> One real problem is: how do we ensure we have checked the myriad of build >> options/environments? The notes on the Wiki are one thing, I guess, and >> the most >> systematic so far. > > One possible solution is provided by kitware (the creators of cmake) called > Dart ( http://public.kitware.com/Dart/HTML/Index.shtml ). It can be also > integrated in cmake scripts. Question is, if it is worth the efforts to set > up such a solution. I think using Dart is an excellent idea. My understanding is the Dart client allows you to set up a nightly automated task to build PLplot, run ctest, and report results to kitware's Dart server (which in turn publishes those results on their website). Once one of the developers is successful setting up a Dart client (which I assume is fairly trivial), they should give the cookbook via the wiki to encourage/recruit Dart testers so that we will obtain as wide a coverage as possible for all the different PLplot platforms. Note, for now users on the bare windows platform will not be able to participate in reporting ctest results for PLplot using Dart because of all the shell stuff we have in the ctests. It will take some hard work to overcome that bare windows ctest issue, but those with Cygwin or MinGW platforms will certainly be able to run ctest and participate in Dart reporting. To answer Arjen's overall question, we have traditionally tested our software in a one-time way with our development releases since many of our users download and build those releases and give us feedback for any problems they encounter for their favorite platform. But I believe we should supplement that approach with Dart (for Linux, Mac OS X, Cygwin, and MinGW platforms to start and ultimately for bare windows as well) since that gives us much better time resolution and with a guarantee of exactly what was tested (the ctest suite of tests). 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); 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: Werner S. <sm...@ia...> - 2006-11-02 09:02:34
|
Hi, > I think using Dart is an excellent idea. My understanding is the Dart client > allows you to set up a nightly automated task to build PLplot, run ctest, > and report results to kitware's Dart server (which in turn publishes those > results on their website). Once one of the developers is successful setting > up a Dart client (which I assume is fairly trivial), they should give the > cookbook via the wiki to encourage/recruit Dart testers so that we will > obtain as wide a coverage as possible for all the different PLplot > platforms. There is also the problem how to set up a Dart server - don't know if some can use the Dart Server of kitware. I think I could provide server space in case my web package meets the requirements (java, etc.) Regards, Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2006-10-31 00:53:23
|
Hi Orion: I am going to post my reply to your question on list because it is a good question...Alan On 2006-10-30 16:33-0700 Orion Poplawski wrote: > Alan W. Irwin wrote: >> I think we should be mentally prepared for a PLplot development release >> in the very near future featuring our CBS. >> > > Cool. I'll probably start working on testing building rpms for Fedora Extras. > One question, what release version will this likely be? 5.6.2? 5.7? 5.7.0 since it is the first development release beyond the 5.6.x series of stable releases. (Odd minor numbers are development releases while even minor numbers are stable releases.) Although this next release is a development release, I hope it will work well for the majority of our users. I want the first impressions of our new CMake build system to be good. BTW, to help insure a high-quality development release we need testing of our CMake Build System (CBS) using the CVS version of PLplot on as many platforms as possible by those most familiar with PLplot (i.e., those lurking on this list.) Thus, I hope that all of you will give our CBS a try on your favorite platform following the instructions at http://www.miscdebris.net/plplot_wiki/ For example, Orion, I don't think anybody has tried it with Fedora yet although it works well on my two Linux platforms (Debian stable and Ubuntu Dapper). 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); 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 __________________________ |