Author Topic: XML based compilers  (Read 187406 times)

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9614
Re: XML based compilers
« Reply #165 on: December 12, 2012, 08:30:43 pm »
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!
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13393
    • Travis build status
Re: XML based compilers
« Reply #166 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?
Happened both at work and at home.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13393
    • Travis build status
Re: XML based compilers
« Reply #167 on: December 13, 2012, 03:26:37 pm »
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 :(
« Last Edit: December 13, 2012, 03:29:28 pm by oBFusCATed »
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9614
Re: XML based compilers
« Reply #168 on: December 13, 2012, 04:50:57 pm »
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?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9614
Re: XML based compilers
« Reply #169 on: December 13, 2012, 04:53:01 pm »
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?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13393
    • Travis build status
Re: XML based compilers
« Reply #170 on: December 13, 2012, 05:33:58 pm »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9614
Re: XML based compilers
« Reply #171 on: December 13, 2012, 05:49:51 pm »
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?!
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13393
    • Travis build status
Re: XML based compilers
« Reply #172 on: December 13, 2012, 05:52:35 pm »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9614
Re: XML based compilers
« Reply #173 on: December 13, 2012, 08:27:05 pm »
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?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13393
    • Travis build status
Re: XML based compilers
« Reply #174 on: December 13, 2012, 09:25:35 pm »
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
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: XML based compilers
« Reply #175 on: December 13, 2012, 11:07:55 pm »
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).

Offline tomjnx

  • Multiple posting newcomer
  • *
  • Posts: 34
Re: XML based compilers
« Reply #176 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).

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.


Offline tomjnx

  • Multiple posting newcomer
  • *
  • Posts: 34
Re: XML based compilers
« Reply #177 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,

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

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: XML based compilers
« Reply #178 on: December 27, 2012, 03:48:38 am »
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.

Offline tomjnx

  • Multiple posting newcomer
  • *
  • Posts: 34
Re: XML based compilers
« Reply #179 on: December 27, 2012, 05:26:43 am »
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