XML based compilers

[MortenMacFly]

Sorry, no time atm, but I'll see what I can do later this or next week.

Done. Branch is successfully merged into trunk now (with only ~10 serious conflicts only, btw. - easy to resolve with the conflict manager of my SVN tool suite ;-)).

Therefore the branch is now obsolete.

A big "THANK YOU" to Alpha for the hard work!

[oBFusCATed]

Any explanation why SDCC compiler is detected as user defined, but I've never change anything in it?
Happened both at work and at home.

[oBFusCATed]

It seems that if there are compile errors and you hit f8, the debugger is not stopped, but continues, no dialog, no nothing.

p.s. this doesn't happen on a simple project

[MortenMacFly]

It seems that if there are compile errors and you hit f8, the debugger is not stopped, but continues, no dialog, no nothing.

p.s. this doesn't happen on a simple project

Is that related to the compiler?

[MortenMacFly]

Any explanation why SDCC compiler is detected as user defined, but I've never change anything in it?
Happened both at work and at home.

Windows or Linux?

[oBFusCATed]

Is that related to the compiler?

I suppose it is. It happens when there are some major header changes and there are more that one compilation commands.
The error is in a cpp file, not a header. I've never seen this bug with the older builds. I'll try to reproduce this with the C::B's
project.

Windows or Linux?

Both linux.

[MortenMacFly]

I'll try to reproduce this with the C::B's project.

That would be nice because I don't understand currently, how a compiler session could interfere with a debugger session?!

[oBFusCATed]

That would be nice because I don't understand currently, how a compiler session could interfere with a debugger session?!

This is if you have the option "Auto-build project if it is not up-to-date" enabled.
So when you start the debugger, first the compiler is run to build the project.
Normally, when the build fails a message pop-up asking you if you want to debug the project anyway.
This popup doesn't show up with the latest build.

[MortenMacFly]

This is if you have the option "Auto-build project if it is not up-to-date" enabled.

done that, started debugging and it stops at the build error, shows the asks if I want to to debug anyways and both options work for me...?!

What do you mean with:

I suppose it is. It happens when there are some major header changes

?

Is there a safe way to reproduce?

[oBFusCATed]

Is there a safe way to reproduce?

Yes, at least on linux.
1. add space to cbeditor.h
2. add some garbage in src/src/main.cpp
3. press f8

[Alpha]

Any explanation why SDCC compiler is detected as user defined, but I've never change anything in it?

Previously, the default master path for SDCC was incorrectly

• Windows: C:\Program Files\sdcc\bin
• Linux: /usr/local/bin

This was fixed during the refactor (the trailing "bin" was removed), but has the side-effect of appearing to be different (the previous saved value no longer matches the default fall-back).

[tomjnx]

I have now updated my Keil C51 and IAR ICC8051 compiler plugin patch to the new XML compiler framework. It can be found here:
http://www.baycom.org/~tom/cb/keiliarcompilers.patch

(It is also at Berlios Patch #3152, but Berlios seems to eat new files from uploaded patches, so the Berlios version is incomplete).

Keil C51 and IAR ICC8051 are commercial compilers for 8051 type microcontrollers.

The options XML files worked great for me!

I'm not so convinced about the compiler XML files. It seems I cannot use them both for Keil and IAR.

For detecting Keil, I need to read a registry key, but then append another path component to the retrieved path. It seems to me I cannot do this with the XML framework.

For detecting IAR, I need to open a registry "directory", enumerate all "subdirectories", read a registry key out of each subdirectory and check the retrieved paths. This seems not doable with the XML framework either.

So both compilers have option XML files, but "old-style" C++ detection routines.

For Keil, I needed to do additional modifications to the compiler plugin and SDK infrastructure.

For one, Keil Return code 1 also indicates success (but with warnings). So I needed to make the highest return code still considered a success configurable (statusSuccess).

Then, Keil has a very peculiar way to specify include paths and defines to the compiler. Instead of the standard "-Ipath1 -Ipath2", Keil wants paths to be specified as "INCDIR(path1;path2)". There can only be one "INCDIR" command line parameter, so "INCDIR(path1) INCDIR(path2)" does not work. To handle this, special processing is triggered when a compiler "switch" ends with "(". Plus configurable separators (includeDirSeparator).

Third, the Keil Linker is unable to find objects by itself in a list of directories. It needs fully resolved paths as input. Therefore, I needed to add path resolution, which is enabled with linkerNeedsPathresolution.

[tomjnx]

A question about SDCC: why has objectExtension been changed from "rel" to "o"? This doesn't work for me,

Also, I need to set linkerNeedsLibPrefix to true, because telling sdcc to -labc makes it try to link abc.lib

[Alpha]

What I'm asking for is to make "o" the default for SDCC object files because "rel" has been totally irrelevant for months.

Done in trunk. I guess nobody of us works with that compiler, so hopefully no other users complain that might still use the version that requires "rel"... we will see...

A question about SDCC: why has objectExtension been changed from "rel" to "o"? This doesn't work for me,

Uh-oh...
Do any SDCC users have a version number where this changed?

I have now updated my Keil C51 and IAR ICC8051 compiler plugin patch to the new XML compiler framework. It can be found here:
http://www.baycom.org/~tom/cb/keiliarcompilers.patch

(It is also at Berlios Patch #3152, but Berlios seems to eat new files from uploaded patches, so the Berlios version is incomplete).

Great.  In a quick peek, however, it appears that the baycom.org upload missed the files compilerIAR.cpp, compilerKeilC51.cpp, compilerIAR.h, and compilerKeilC51.h.

I'm not so convinced about the compiler XML files. It seems I cannot use them both for Keil and IAR.

Yes, these auto-detection routines are very basic; only the simpler compilers can make use of them currently.  However, if you happen to have any ideas or suggestions for a better file format, I would appreciate hearing them.

[tomjnx]

A question about SDCC: why has objectExtension been changed from "rel" to "o"? This doesn't work for me,

Uh-oh...
Do any SDCC users have a version number where this changed?

I don't think it ever has changed or become irrelevant. The SDCC manual
http://sdcc.sourceforge.net/doc/sdccman.pdf states on p.24 that the object file extension is .rel.

Looking at the sourceforge SVN source code of SDCC, it's slightly more complicated. AVR, DS390, HC08, MCS51, XA51 and Z80 ports use .rel as object extension, only the PIC14 and PIC16 backends use .o as object extension (see sdcc/src/*/main.c, the PORT structs). I'd consider the PIC backends as of the lesser stable/mature backends - so it seems strange to break the stable backends because of a few unstable ones...

So it seems the correct fix would be (apart from convincing SDCC developers to use the same extension for all backends) to select the object file extension based on which architecture switch was selected...

Great.  In a quick peek, however, it appears that the baycom.org upload missed the files compilerIAR.cpp, compilerKeilC51.cpp, compilerIAR.h, and compilerKeilC51.h.

Sorry about that, should be fixed now