compileIt for revolution?

[Alex Tweedly]

Richard Gaskin wrote:

> <comments on the externals SDK... snipped>
> Has it been logged as a request to BZ?  It would be great to see those 
> addressed.
>
No, it hasn't - but only because Mark has seen it, and responded to me, 
and I've sent him more suggestions directly, ... and so I'm comfortable 
they will be incorporated into the next version of the SDK; otherwise I 
would create a BZ to put them in.

> This seems like an opportunity here for someone who's worked 
> successfully with the SDK to consider teaming up with others to make a 
> nifty Rev-based IDE specifically for making Rev externals.  By taking 
> care of all the tedious stuff, it could make crafting externals a lot 
> more fun -- and you wouldn't have to leave you C environment for 
> testing, since it'd all be under one roof. :)
>
> Could this be done by generating make files and running GCC through 
> shell(), or am I dreaming?
>
Yes, I think it could be - though I haven't tried it yet.

I'm not so sure about building a useful Rev-based IDE for externals.
Such an IDE would need to consist of the following parts:

 - code editor. Doable - though building a code-aware editor with 
formatting and color (very useful for C) is far from trivial. Might be 
possible to hive this off to an external editor (emacs, BBedit, etc.)

 - create/manage additional files (makefiles, .def files if they're 
needed, etc.) Definitely doable and useful.

 - debugger. Probably impossible.

The "create and manage" files part would be useful in itself (though 
possibly need to handles a number of variants for different compilers); 
and that might be very helpful for people starting to look at externals.

But when writing C externals, I found it pretty easy to follow bad 
pointers, or all the usual C problems - each resulting in access 
violations and termination of the Rev IDE. So I believe a useful IDE for 
C (nowadays) *must* provide a protected environment for running the 
code, and really should provide integrated debugging.

The only way I've found to avoid repeated crashes was to build a small 
"support system" to emulate a small part of the Rev interface, and the I 
can build my external and some test programs in C, test and debug the 
"test prog+external" bundle within a real C environment (Bloodshed in my 
case). Only once I've got that working and at least mostly debugged do I 
try the external from Rev.

This may be purely a result of my poor C programming (although I wrote C 
full-time for a few years, that was nearly 20 years ago, so I really 
have forgotten more about writing C than I still remember). But I 
suspect that most people who aren't experienced, current C programmers 
would find it much the same.

I'd love to hear about the development and testing techniques used by 
experienced external developers.

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.8/35 - Release Date: 30/06/2005