Compiler framework redesign (?)

[nzoltan]

Hi,

If you really want redesign the compiler framework, I recommend that see CBuilderX IDE.

announce (1.5 for windows free edition):
http://bdn.borland.com/article/0,1410,32751,00.html

download (after 7 q&a): 133MB
http://info.borland.com/survey/cbx15_mobile_edition.html

Also you will need a Borland Developer Network registration (free). It is an excellent cross platform IDE - and "just" an IDE - (similar for C::B) support many of compiler sets (every compiler described an extension XML file, and the user can create new easy), but unfortunately CBX has many many many bugs and totally unsupported by Borland (dead project).

Major features:

- Build options dialog not just for project but for every file
- Multiple build tools (and options) for same project (example: msvc on windows, gcc on linux)
- Project file can be "excluded" (ignored when build, but show is the project)
- Project tree also contain the final binary file entry (exe, dll, so, a, lib etc.) and have a build options dialog
- Build options dialog show a final preview of compiler command line (build tool and every local and inherited options)
- Revert menu for editor tabs

...and many more features.

Good luck,
a new C::B user.

[Game_Ender]

I think a preview of the final command line would be a useful feature.

[MortenMacFly]

- Build options dialog not just for project but for every file
- Multiple build tools (and options) for same project (example: msvc on windows, gcc on linux)
- Project file can be "excluded" (ignored when build, but show is the project)
- Project tree also contain the final binary file entry (exe, dll, so, a, lib etc.) and have a build options dialog
- Build options dialog show a final preview of compiler command line (build tool and every local and inherited options)

All this is achievable with C::B, too. See my sig and have a look at C::B file properties, too.
With regards, Morten.

[killerbot]

I think he is talking about a preview of how the command line looks with just all the settings appended (so no macros replacement yet) and whitout issuing a build. Several IDE's show it like that (some read only) others even editable.

[nzoltan]

All this is achievable with C::B, too. See my sig and have a look at C::B file properties, too.
With regards, Morten.

- Build options dialog not just for project but for every file

In C::B, the file build options dialog and project options dialog is very different, CBX provide same dialog.


- Multiple build tools (and options) for same project (example: msvc on windows, gcc on linux)

I can`t do this with C::B:
1. I select the project, 2. right click 3. select properties menu
then I cannot change compiler because the drop-down list is grayed.


- Project tree also contain the final binary file entry (exe, dll, so, a, lib etc.) and have a build options dialog


In CBX this dialog show the linker options.


----
Sorry my english is very poor, and at this time, I am only present perfect (with bugs).

[nzoltan]

I think he is talking about a preview of how the command line looks with just all the settings appended (so no macros replacement yet) and whitout issuing a build. Several IDE's show it like that (some read only) others even editable.

Exactly! But I think, a read only preview is abundant.

[chikigai]

Hello,

Hope I'm not going to off topic here, but since it may relate to the Compiler framework redesign, I'm putting the details here.
I was thinking of using the ARM9 compiler through Code::Blocks (without custom makefiles) but ran into a few difficulties.
The main difficulty is that the ARM9 compiler suite has the following utilities:

1. ASM Compiler
2. C Compiler
3. C++ Compiler
4. Librarian
5. Dynamic Linker
6. Static Linker

Basically, the number of utilities is far larger than the basic set most compiler suites have.
When a project contains a combination of C and Assembly files, the difficulty increases since the define switch is different between the ASM and C compiler ('-D' for the C compiler and '--PD' for the ASM compiler).
I thought about extending the Compiler Framework but it is next to impossible without breaking what's already in place.

I was wondering if the planned XML based Compiler Framework would allow integration of compiler suites of this nature.

Yes, I understand that the integration of this sort of compiler suite probably does not match what Code::Blocks is intended/planned to support, but again, I was just wondering!

[mandrav]

I was wondering if the planned XML based Compiler Framework would allow integration of compiler suites of this nature.

Short answer: yes.

[chikigai]

Thanks for the quick reply!
Will wait patiently for the new framework! 

[kingfox]

How about the progress of redesigning the compiler framework ?

[mandrav]

How about the progress of redesigning the compiler framework ?

No progress. This is planned for v2.0.

[lescho]

Hello,

during the weekend I tried to add the GCC AVR32 compiler to CB. A just copied the ARM sources and added the new stuff to the compiler factory. It works but I'm not quite happy with the process of adding a compiler. A solution like the one described at the beginning of this thread would be much more convenient. Does someone has this on the agenda?

Another thing is that I've to change the actions of the 'Run' command. As I can't simply execute a AVR32 elf on my PC, I like to execute the external avr32program tool to program the image into the corresponding target MCU. I didn't found anything about that in the compiler plugins. Can someone point me to the right direction.

Thanks Lescho

[dasfoo]

Hello,

during the weekend I tried to add the GCC AVR32 compiler to CB. A just copied the ARM sources and added the new stuff to the compiler factory. It works but I'm not quite happy with the process of adding a compiler. A solution like the one described at the beginning of this thread would be much more convenient. Does someone has this on the agenda?

Thanks Lescho

I'm poking around at this. With an eye to adding the Yagarto compiler this way. Currently working on the code to save and load compiler definitions from an xml file(s).  Currently I'm looking at how ConfigManager handles the default.conf file so as to keep things consistent and not reinvent the wheel.

[dasfoo]

An issue to address, especially with the AVR compilers is that it's possible for there to be more than one compiler installed.

For instance I have, WinAVR-20071221 and WinAVR-20090313 installed.  For a few older projects I need the 2007 version because it produces slightly smaller code.  But for new projects I'm using 20090313.

Seems that it would be a good idea if the AutoDetectCompiler routine would do a little more than detect the first compiler in the path, it should grind through the path and look for all instances and report any it finds.

Another nice thing would be if the Auto Detect routine would ask the compiler to report it's version information.  AKA arv-gcc -v returns gcc version 4.3.2 (WinAvr 20090313)