Organizing Changes for an Embedded version.

[Paul Breed]

I'm building a version of DEV-CPP for
use as an embedded development environment.

I will be replacing/modifiying a number of menus.
(It make no sense to have resources in an embedded system for example)
What is the best way to organize the menus in Delphi so I can have two sets standard and embedded?

I wish to have two sets of some of the dialogs for instnace as well......
when you launch the debugger one must open a remote session and that requires extra parameters that differ by environment.

Lastly I believe that the makefile generation will need to be modified as well. so two versions of compiler.pas etc...

Any suggestions on how best to organize this
so it can be merged into the DEV-CPP main line?

I'm new to Delphi, but my first though would be to seperate out the changes into a seperate unit(s) and then just select which unit was to be used at compile time.  Alternativly we could make it
a run time selection and incldue both units.

Paul

[Colin Laplace]

>I will be replacing/modifiying a number of menus.
>(It make no sense to have resources in an embedded >system for example)
>What is the best way to organize the menus in Delphi so I >can have two sets standard and embedded?

I would say just hide them at runtime during the form creation. We may not need to make a special build for targetting embedded system, if we put an option in Environment Options for example. i would prefer that idea, so you could try to do the changes at runtime, depending on a embedded flag set to true or false.

>Lastly I believe that the makefile generation will need to >be modified as well. so two versions of compiler.pas etc...

i would not say so. The makefile generation is kinda generic. For an embedded environment, just the compiler names will change (like arm-gcc instead of gcc etc...), and this is already customizable in Compiler Options.

if i missed something, please tell me :)

Greetings,
Colin

[Paul Breed]

Changes to makefiles.
In a PC environemnt the Linker script part of the build  is almost unchanged, only real differences is Debug vs Release,

in an embedded system it is the heart of how
the system is configured, an embedded system can have four or more legitimate makefile targets:

Build a Debug version for RAM/Emulator
Build a Debug version for Flash/Rom
Build a release version for RAM/Emulator
Build a release version for Flash/Rom

and in my companies particular case
Build a compressed release image for flash
Build a compressed debug image for flash

To solve all of this I was goint to try and build a general purpose DLLinterface so different people could easily create their own makefile generation
code and install it as an optional DLL.

This interface would also enumerate the
the possible makefile targets and the menu stuff
would automagically pick up these targets and make the aprorpiate menu additions/deletions.

At a minimum the core of this  needs to be put into a seperate unit.

[Colin Laplace]

Ok, i see now.
The DLL approach is a good idea

Greetings,
Colin

[Anonymous]

Makefile-Generation:
some embedded compiler don't have the same options like gcc (-L does not exist for the compiler for TeakLite Chip for example). So, the best thing is to make all compiler options configureable.

The confirm messages about read-only-files are
really annoying. it is better to give the user the possibility to disable it.