Adding support for some more compilers...

[stardust]

Hi there,

as I am planing to add support fore some more compiles to C::B, I have some questions:

• =1=
  The compilers belong to the GCC family of compilers. However, the targets (which shall mean "target systems" here, not to confuse with "makefile or build targets") are rather MCU than CPU, i.e. the generated software will run on an embedded system (TriCore, MSP430, PowerPC, ...). Up to now, C::B only addresses the development for host software. So I am curious if such extensions are welcome in C::B and if it is worth the effort of submitting patches that add this support...
• =2=
  Adding these compilers is not too much work. I just had to clone a ./src/sdk/compiler* and that's it. What is about the new XML compiler description? If the XML framework comes soon, there will be no more need to add the support into a core plugin.
• =3=
  In this and some other forums the discussion on a new XML representation always uses the term compiler where IMO toolchain should be used (For MSCV these may be identical and even most users of GCC just regard it as C/C++ compiler, whereas is it a bunch of tools). As I can imagine, the new framework will bring support for all tools in a chain like compiler (foo-gcc), assembler (foo-as), linker (foo-ld), archiver (foo-ar), a.s.o? For embedded there is often the need to control the build process in a more sophisticated manner than for host applications: Specify special options for assembling, linking, providing own startup code, specifying own linker description file, etc.
• =4=
  The most complicated part will be to integrate a debugger into C::B. To "RUN" Software on an MCU, you have first to download it to the target hardware and then start it. This is not as easy as just call the generated executable. Moreover, integrating a debugger means that there must be a notion of the target system by means of GPRs, SFRs, Memory, a.s.o. These is no way to debug on source level (changing source (i.e. code) when debugging).
  
  Therefore, it was fine to control the behaviour of "RUN" or "DEBUG" in some way...

So I hope I am not completely off topic.

[mandrav]

I 'd suggest you wait for the new framework (I don't have any timeframe to give you though).

[stardust]

Yes, reviewing and adding patches will take time...

To be more concrete. The very implementation I will do on my own. I do not expect anyone to do my work for me ...;-)

I will then, of course, translate the stuff into XML if time is ready. At this point it's rather the question how much participation is desired and if all this fits the focus of C::B.

[Game_Ender]

What branch is the new compilier framework developement being done on?  I couldn't find it.

[MortenMacFly]

What branch is the new compilier framework developement being done on?  I couldn't find it.

It's called "cf". But I believe it's quite out-dated. Dunno if Thomas did some more work on that and hasn't committed yet...

[MZet]

Please add Orcas support, it isn't very difficult to do I think?

[JSThePatriot]

I hate to bring up an old thread, but I am being forced (work ) to code with eMbedded C++, which I have to download a very old IDE and Compiler. 4.0 is the most recent version on M$'s website. Is anyone looking to include eMbedded C++ as an option for C::B?

Thanks,
JS

[MathStuf]

Rather than extending C::B for every compiler, is it possible to include a way to allow users to define their own compilers?

--MathStuf

[Mc.Michael]

Please add Orcas support, it isn't very difficult to do I think?

+1

[MortenMacFly]

Guys,

adding a compiler is not really difficult. Just take one look into the code in the compiler plugin (basically one *.cpp/*.h file per compiler). Try to adjust for your compiler and submit a patch. We cannot add support for compiler we don't know. This can be done at best by "experts" using these compilers. Everything else would definitley be error prone.

For the embedeed C++ stuff I'd say start with the visual toolkit compiler. For the others I don't know as I don't know them.

With regards, Morten.