Re: [Oopic-compiler-devel] Summary

[Neil D. <nd...@us...>]

Good questions!

D. Daniel McGlothin wrote:
> A new category:
> Is the tool to support all firmware revisions of the OOpic?

I say definitely - aim for the most recent firmware revision, and then we
just disable features that aren't present in lower OOPic versions.  Unless
the compiler has bizarre workarounds for quirks in each OOPic version?

> A new category:
> Testing is going to be done how?  What is the testing methodology, etc?  Do
> any of us have a suit of OOpic in the tools supported firmware revisions?
> If not, are we going to ask Scott Savage for a few freebies?

We can probably test the bulk of our work by simply comparing the generated
op-codes with those from Scott's compiler, using 'equivalent' code.  This
will be especially useful for testing object support, which I guess won't
be changing much from the existing compiler, beyond maybe giving errors
when someone tries to access vapourware.  Plus, I don't think testing
against actual sonars, motors, compasses etc is going to be practical!

However I guess that'll only work so far, and we'll need to do testing
against real hardware for some stuff.  I have an OOPic II+ (b.2.2+) and an
OOPic II (b.1.0).

Perhaps for the various bits of hardware we don't have, we could recruit
a couple of beta testers from the OOPic forum who have the required
itarget hardware.

Same applies for different development systems - for example for the
Windows compiler we're going to have to test on Win95/98/ME/NT/2000/XP.

Of course, as it's open source, I guess it's reasonable to release it
having tested it on the hardware we have, and list the hardware it's been
seen to work on.  Then people can test it on their own hardware and report
back, in the true spirit of open source knowledge sharing!

I think we'll be lucky if Scott gives us some freebies!

> A new category:
> Installer issues have been recently discussed on the OOpic list.  What
> 'installer' issues will this project need to address?

Well, I think the installer issue has come up because of the IDE's
dependency on VB runtime files, which may/may not be present on a given
system, and may not be the correct version.

I'm hoping that our compiler will be pretty self-sufficient, not relying on
installed DLLs or libraries, and so it should be a simple operation of
putting the compiler exe somewhere on the path.  If the compiler depends on
Windows DLLs etc, then we will have lost cross-platform compatibility as
there are no equivalents to the various Windows DLLs on DOS, Linux and
MacOS.  I think considering the target audience, it would be acceptable to
make a static build with any libraries compiled in.

I should be able to "find" a copy of InstallShield for creating a proper
installer for Window.  For DOS, I guess we can get away with a batch file
or similar.  And for Linux I think it would be acceptable to ship it as a
source code .tar.gz file with compilation instructions (this is widely
regarded as reasonable on Linux).  Alternatively it wouldn't be hard to
create ready-compiled RPM or DEB files for Linux.

One question that arises from this - are we intending to allow out compiler
to work as a drop-in replacement for the existing compiler, ie so that it
works from the existing IDE.  If so, then the installer will have to locate
the currently-installed compiler, rename it, and replace it with the new
one.

Neil
-- 
Neil Durant
<nd...@us...>