Re: [orbitcpp-list] idl compiler has arrived

[Phil d. <ph...@us...>]

Hi Andreas,

Andreas Kloeckner wrote:
> 
> Hi phil, hi list,
> 
>   the compiler's in sourceforge cvs. for me, it does compile, it does
> install, but it does not do anything even remotely sensible ;)

Everything compiles for me too (hurrah!). Ron - can you compile and run
the code on solaris - If there's a segfault problem I want to catch it
now.

> Some other things you should know about:
> 
> * configure.in now has special handling (should i say "kludge") for
> --enable-debug. I do not believe this is very well written, but heck, it
> prevents me from growing a dwarf's beard while compiling everything with
> "-O2" on.
> 

Okay. Actually I'd prefer that the default is to leave the debug code
in, and have an '--enable-optimized' or something for cast-iron
releases. That way we're more likely to be able to get people using
development releases to send us stack traces.

> * i put the two tests i had created so far in the tests directory. (they
> are basic/ and idl-torture/, where "basic" is just plain understatement
> for the kind of test. it features basic types, strings, typedefs,
> scoping, diamond of death inheritance, object reference passing back and
> forth, well, all this really _basic_ stuff B-> ... first job should be
> to get this baby working again, i guess.)
> 

Sounds good. BTW, the 'check' target is meant to run the tests rather
than build them - I couldn't get this to build so I've removed
idl-torture and basic from the test Makefile.am so that the global check
target runs. 
I'd like to aim to keep the 'make' and 'make check' global targets
always working, and we'll just add tests to them when they're finished
and working.

> * phil, i know you hate my indentation style, so if you want to do
> something about it (or got a tool to do so), now is the time. 

It's not just your code - I've been lazy and used about 3 or so
indentation styles during the course of developing ORBit-C++ so the code
isn't at all consistent.
I think we should choose one of the standard indentation styles and go
with it. I'll send a post later addressing this once I've found what I
did with that C++ indentation tool.

> (while
> you're at it, you may also make a mess of my nice-and-plain (tm) source
> file headers to keep things uniform) (if you tell me what to do, i will
> help out) (call this stage "one" (tm))

I use the 'stick a gnu license (gpl/lgpl) in every file' because that's
the way it has worked on other projects I've hacked with. This does mean
that anybody wishing to pinch code from the file immediately knows the
implications.

As regards copyrights, we've sort of used the informal 'the person who
creates the source file has the copyright, and anybody ammending the
file can add their name to the authors list in the file header' rule as
we've been developing (although I don't think anybody decided this). I'd
like to keep that if there isn't a good reason to change it.

> * and for the final and most important question: what is to be done
> next, after stage "one" (tm) is complete? ya, get the thing to work,
> right. i almost forgot. :) but in what order? and _who_ does _what_? i'm
> currently preparing for a math exam, so there's not too much time, i'll
> see what i can do. (say, an hour or so each day) first thing i would
> look into is doing some cleanup on the idl compiler, to remove the
> clearly o2cpp-specific parts (and perhaps code new ones for your
> runtime). yet, this requires completion of stage "one" (tm) :)
> 
> tell me about your plans. i wanna get goin'!
> 

Erm, good question!

I think:

1) Get the 'string test' stubs and skeletons in a shape that we're happy
with - that way we have an example of stubs and skeletons which allows
gives us something to shoot at.
Actually they are probably almost there now - I'd appreciate it if you
could have a look and check that there aren't some obscene optimisations
I'm missing or something that would make things much simpler. 

2) Aim the compiler at that.

3) Keep adding features...

As for who does what:
It'd probably be simpler if we split the compiler work into 'you do the
stubs, I'll do the skeletons' or something like that. 

Phil.