[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compile on Cray/ nonGNUcompiler
From: |
Daniel Heiserer |
Subject: |
Re: compile on Cray/ nonGNUcompiler |
Date: |
Tue, 01 Feb 2000 08:46:05 +0100 |
address@hidden wrote:
>
> On Mon, 31 Jan 2000, Daniel Heiserer wrote:
>
> > That would be easy for me. I can run it thru tons of other compilers.
> > If there is somebody who can fix it AND wants to fix it in the way
> > that octave is 100% ANSI C++ (what I think is not the worst idea.)
>
> You're of course correct, but do keep in mind that not everybody wants
> to (or can!) jump to the latest and greatest compilers that tend to break
> lots of existing code. If you really want a surprise, try IBM's latest
> VisualAge C++.
>
> Now on to topic at hand -- here're the various pieces that need to be
> changed to make Octave compile with a reasonably conforming compiler
> (note that I don't consider any versions of GCC released to date to be
> "reasonably conforming"):
>
> Here's a few things from memory when I looked into this a while back.
>
> Simple things:
>
> 1. Fix up readline headers. Currently these use K&R declarations.
> 2. There were a few issues in kpathsea as well, but probably fixed
> by now (my own packages use an older version that did fixing).
>
> 3. Fix up non-conformant forward decls, such as:
>
> class ostream;
> class string;
>
> etc and replace these with the appropriate include statements.
>
> 4. Fix up configure to handle non-GNU compilers. It should generally
> work, but won't in the following cases:
>
> a. Make sure you tell configure to use an ANSI C compiler. The current
> check for f2c compatible F77 compiler will fail otherwise. Easy to
> fix of course.
> b. Other issues such as creating .d files won't work, but again
> there're well established/known methods to make these portable.
> c. Little things like -shared flags may not be acceptable, and you may
> need to use something else (eg., on Solaris, gcc will accept
> -shared, but CC will only take -G). Again, easy to fix.
>
> 5. GCC allows certain accesses that are illegal (due to bugs in scope
> handling in GCC, not because GCC is trying to help you ;-). I remember
> a case or two in Octave, and easily fixed.
>
> Simple, but very tedious things:
>
> 1. Fix up all usages of std:: namespace symbols! When I moved to EDG
> based compilers, this was what took me the most time to "fix"
> a large package. I don't care for my own sofware to be compilable
> by older compilers, so my solution was simple -- prefix each
> occurance of iostream, string etc with std::. The rest of my code
> was already namespaced, so the transition was quite trivial.
>
> Quality of Implementation issues:
>
> 1. Fix up various variable shadow'ing issues in Octave. Octave's code
> has a few cases where the class data member names and the name of a
> parameter to a method coincide. I tend to name data members so that
> this doesn't happen, but that's a style/guideline issue.
>
> The current shadowing in Octave is unlikely to lead to bugs because
> of the relatively decent type-safey in C++, but it'd be nice to get
> rid of these.
>
> I probably have most of these changes sitting in a CVS branch somewhere,
> and if you someone really wants it, I'll dig it out.
>
Of course I really want it. Would be very nice for me to have
octave on a vector-machine :-)
So could u try to find it?
Maybe it can be added to the ditribution ones in runs, so further
distributions run on even more platforms...
> If you really want to try good compilers, try out KCC or something based
> on EDG.
What is KCC and EDG, where do they come from?
Thanks Daniel
-----------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.
Octave's home on the web: http://www.che.wisc.edu/octave/octave.html
How to fund new projects: http://www.che.wisc.edu/octave/funding.html
Subscription information: http://www.che.wisc.edu/octave/archive.html
-----------------------------------------------------------------------
- Re: compile on Cray/ nonGNUcompiler,
Daniel Heiserer <=