Re: compile on Cray/ nonGNUcompiler

[Daniel Heiserer]

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
-----------------------------------------------------------------------