From: Werner S. <sm...@ia...> - 2006-10-09 10:10:18
|
Hi, I managed to make plplot compile with the Open Watcom compiler (http://www.openwatcom.org) and was also able to run x01c with the wingcc driver. There were some problems though: 1) wmake, the watcom make, doesn't like '+' in filenames - therefore it doesn't compile the c++ bindings. The most simple solution would be to just rename the c++-bindings directory to cxx and make appropriate changes everywhere. The only drawback would be (at least I think so), that we loose the 'history' of these files in cvs, since cvs can't rename files. What do you think about that? 2) watcom knows isnan, but CBS doesn't find it, since isnan is defined in math.h. So check_function_exists(isnan HAVE_ISNAN) doesn't work, we would need a similar solution like for TestBrokenIsnanCXX.cxx. Should I do the changes or is there a possibility for check_function_exists to add a header before (cmake documentation doesn't say so). 3) There is also problem with the export of plsc, which clashes with changes Arjen did, but we try to figure this out. Apart from that it seems, that also Open Watcom is now supported (thanks to CBS). And Open Watcom has also a fortran compiler - but this needs still to be tested. 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-09 19:02:22
|
On 2006-10-09 12:09+0200 Werner Smekal wrote: > Hi, > > I managed to make plplot compile with the Open Watcom compiler > (http://www.openwatcom.org) and was also able to run x01c with the > wingcc driver. This takes me back a long way. I did a lot of my programme development as a graduate student (in the 70's) using the WATFOR (Waterloo Fortran) compiler. That compiler was probably one of the better fortran compilers available at that time for IBM equipment. If you read the openwatcom history, WATFOR was the first step in the openwatcom effort. It sounds like after a semi-open beginning they closed the compiler development effort for a long time, but now they are beginning to reopen it again. However, in my opinion, they are too tentative about this. The lack of Linux platform is a problem for this compiler. According to http://www.openwatcom.org/index.php/Win32ver_on_Linux openwatcom partially works under wine/linux, but that is insufficient. > There were some problems though: > > 1) wmake, the watcom make, doesn't like '+' in filenames - therefore it > doesn't compile the c++ bindings. The most simple solution would be to > just rename the c++-bindings directory to cxx and make appropriate > changes everywhere. The only drawback would be (at least I think so), > that we loose the 'history' of these files in cvs, since cvs can't > rename files. What do you think about that? Since openwatcom.org is an open-source project, I think your best bet is to make a bug report there to insure they support valid directory/filenames. The alternative of changing bindings/c++ AND examples/c++ to the cxx form means quite a few changes to not only our CBS, but also our ABS. This is in addition to the issue you pointed out of losing all the history for all files in the two c++ directories. > > 2) watcom knows isnan, but CBS doesn't find it, since isnan is defined > in math.h. So check_function_exists(isnan HAVE_ISNAN) doesn't work, we > would need a similar solution like for TestBrokenIsnanCXX.cxx. Should I > do the changes or is there a possibility for check_function_exists to > add a header before (cmake documentation doesn't say so). I am not sure. I think you are going to have to experiment with check_function_exists (paying close attention to its log-file results) to find out. If that continues to not give what you need, then the alternative of writing a special check is fine as well. > > 3) There is also problem with the export of plsc, which clashes with > changes Arjen did, but we try to figure this out. > > Apart from that it seems, that also Open Watcom is now supported (thanks > to CBS). And Open Watcom has also a fortran compiler - but this needs > still to be tested. Good work. I will also be most interested to see how well it does for our two fortran (f77 and f95) interfaces. 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-10 07:01:12
|
Alan W. Irwin wrote: > >Good work. I will also be most interested to see how well it does for our >two fortran (f77 and f95) interfaces. > > > I started with some preliminary tests for the Salford C and Fortran compiler (these are available in a free personal edition). These compilers have a good reputation in being rather strict and having good debugging facilities. The C compiler complained about a number of errors in our source files that other compilers did not notice or gave warnings about. I did not have time yet to look into them, but I think it is worth checking these. (I got interested in them, as Michael Michelsen would like to use PLplot with the Salford Fortran compiler. The command-line interface of these compilers is not quite what I am used to, so that takes some learning.) Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-10-16 08:28:57
|
Hi Arjen, > I started with some preliminary tests for the Salford C and Fortran compiler > (these are available in a free personal edition). These compilers have a > good > reputation in being rather strict and having good debugging facilities. I found the salford Fortran compiler, but not the c-compiler from salford - where did you download it from? 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-10 07:25:48
|
Hi, > The C compiler complained about a number of errors in our source files that > other compilers did not notice or gave warnings about. I did not have time > yet to look into them, but I think it is worth checking these. Visual C++ 2005 gives also tons of warnings, especially about the use of sprintf (instead of snprintf), deprecated features (according to the C99 standard) and unused variables. Question is, if we should change the code accordingly - I would highly suggest it and would also do some work on it - or are there some opinions against such changes? 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: Arjen M. <arj...@wl...> - 2006-10-10 07:34:05
|
Werner Smekal wrote: > Hi, > >> The C compiler complained about a number of errors in our source >> files that >> other compilers did not notice or gave warnings about. I did not have >> time >> yet to look into them, but I think it is worth checking these. > > > Visual C++ 2005 gives also tons of warnings, especially about the use > of sprintf (instead of snprintf), deprecated features (according to > the C99 standard) and unused variables. Question is, if we should > change the code accordingly - I would highly suggest it and would also > do some work on it - or are there some opinions against such changes? Well, warnings I have seen from Visual C/C++ 6.0 (the ancient one) are mostly about longs being implicitly converted to ints and the like. Adding explicit casts may silence the compiler, but the code is not going to work better and certainly is not going to be more readable - in my opinion. I think we will need to be careful here. I vote yes to these issues: - remove unused variables (makes the code less confusing) - check the use of sprintf() (makes the code safer) - functions that do not return a value but should (makes the code safer too) I do not know enough about C99 to comment on deprecated features, but I would not like to see explicit casts all over the place. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-10-10 16:13:52
|
On 2006-10-10 09:33+0200 Arjen Markus wrote: > Werner Smekal wrote: > >> Hi, >> >>> The C compiler complained about a number of errors in our source >>> files that >>> other compilers did not notice or gave warnings about. I did not have >>> time >>> yet to look into them, but I think it is worth checking these. >> >> >> Visual C++ 2005 gives also tons of warnings, especially about the use >> of sprintf (instead of snprintf), deprecated features (according to >> the C99 standard) and unused variables. Question is, if we should >> change the code accordingly - I would highly suggest it and would also >> do some work on it - or are there some opinions against such changes? > > Well, warnings I have seen from Visual C/C++ 6.0 (the ancient one) are > mostly > about longs being implicitly converted to ints and the like. Adding > explicit casts > may silence the compiler, but the code is not going to work better and > certainly > is not going to be more readable - in my opinion. I think we will need > to be > careful here. I vote yes to these issues: > - remove unused variables (makes the code less confusing) > - check the use of sprintf() (makes the code safer) > - functions that do not return a value but should (makes the code safer too) > > I do not know enough about C99 to comment on deprecated features, but > I would not like to see explicit casts all over the place. Werner, I think Arjen's suggestions are good ones about limiting the kind of changes you do. Also, to make sure you are not introducing any new issues, I suggest you start conservatively with a few sample changes, and let me test them on Linux/gcc before you apply those same kind of changes to all source files. 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-10-16 08:31:41
|
Hi, >> Well, warnings I have seen from Visual C/C++ 6.0 (the ancient one) are >> mostly >> about longs being implicitly converted to ints and the like. Adding >> explicit casts >> may silence the compiler, but the code is not going to work better and >> certainly >> is not going to be more readable - in my opinion. I think we will need >> to be >> careful here. I vote yes to these issues: >> - remove unused variables (makes the code less confusing) >> - check the use of sprintf() (makes the code safer) >> - functions that do not return a value but should (makes the code safer too) >> >> I do not know enough about C99 to comment on deprecated features, but >> I would not like to see explicit casts all over the place. > > Werner, I think Arjen's suggestions are good ones about limiting the kind of > changes you do. Also, to make sure you are not introducing any new issues, > I suggest you start conservatively with a few sample changes, and let me > test them on Linux/gcc before you apply those same kind of changes to all > source files. As you suggested I wanted to "solve" one major issue and propose the changes to the list - if all agree (i.e. nobody disagrees) I wanted to change all similar issues. And then the next major issue and so on.... But I'm working in the moment on other stuff (qhull, etc.) so this will have to wait a little. 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 |