Developer forums (C::B DEVELOPMENT STRICTLY!) > Compiler Framework Redesign
XML based compilers
Alpha:
--- Quote from: oBFusCATed on December 13, 2012, 02:01:41 pm ---Any explanation why SDCC compiler is detected as user defined, but I've never change anything in it?
--- End quote ---
Previously, the default master path for SDCC was incorrectly
* Windows: C:\Program Files\sdcc\bin
* Linux: /usr/local/binThis 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:
--- Quote from: MortenMacFly on December 01, 2012, 08:09:20 am ---
--- Quote from: squalyl on November 30, 2012, 11:39:51 pm ---What I'm asking for is to make "o" the default for SDCC object files because "rel" has been totally irrelevant for months.
--- End quote ---
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...
--- End quote ---
--- Quote from: tomjnx on December 27, 2012, 02:00:36 am ---A question about SDCC: why has objectExtension been changed from "rel" to "o"? This doesn't work for me,
--- End quote ---
Uh-oh...
Do any SDCC users have a version number where this changed?
--- Quote from: tomjnx on December 27, 2012, 01:54:38 am ---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).
--- End quote ---
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.
--- Quote from: tomjnx on December 27, 2012, 01:54:38 am ---I'm not so convinced about the compiler XML files. It seems I cannot use them both for Keil and IAR.
--- End quote ---
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:
--- Quote from: Alpha on December 27, 2012, 03:48:38 am ---
--- Quote from: tomjnx on December 27, 2012, 02:00:36 am ---A question about SDCC: why has objectExtension been changed from "rel" to "o"? This doesn't work for me,
--- End quote ---
Uh-oh...
Do any SDCC users have a version number where this changed?
--- End quote ---
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...
--- Quote from: Alpha on December 27, 2012, 03:48:38 am ---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.
--- End quote ---
Sorry about that, should be fixed now
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version