Compiler list...

[commontater]

Two quicky questions...

1) How do I hide unused compilers from the dropdown list... (I find it massively annoying have to go through 20+ entries with only 2 compilers installed)

2) Why, when I add a custom compiler to the list, does it prompt me for a default compiler every time I start the program?

[gd_on]

I agree with you for this long list.
Nevertheless, I think this long list is normal for settings/compiler menu, because it shows all the compilers which are known in C::B by default But, for a per project configuration, I think, as you, that it could be nice if only compilers configured on a specific machine (correct paths and programs correctly initialized in General Settings) are proposed.
For your second point, I have myself several custom compilers (gfortran, g95), but I have not your problem. It works well. Did you fill correctly the paths and programs in settings ? Is default.conf file correctly updated (within your profile on Windows or in .codeblocks on Linux) ? Have you a correct write access to this file ?

gd_on

[commontater]

I agree with you for this long list.
Nevertheless, I think this long list is normal for settings/compiler menu, because it shows all the compilers which are known in C::B by default But, for a per project configuration, I think, as you, that it could be nice if only compilers configured on a specific machine (correct paths and programs correctly initialized in General Settings) are proposed.

I agree it's no problem in the global list.

But a project's settings should reflect only compilers enabled for that particular job.  *Especially* if custom compilers are going to be at the end of the list.

So there's no way to hide the unused ones... Bummer!

For your second point, I have myself several custom compilers (gfortran, g95), but I have not your problem. It works well. Did you fill correctly the paths and programs in settings ? Is default.conf file correctly updated (within your profile on Windows or in .codeblocks on Linux) ? Have you a correct write access to this file ?

Maybe that's just me not being fully up to speed on Code::Blocks just yet... there was some other wierdness as well. 
I'll try a reinstall and see what happens.

[stahta01]

Sounds like a good idea to add an Disable option to the Global Compiler List and then only show the compilers that are not disabled on the project list.

The feature request site is
http://developer.berlios.de/account/login.php?return_to=%2Ffeature%2F%3Ffunc%3Daddfeature%26group_id%3D5358

Tim S.

[timojaask]

Did you find any solution to that second problem?

Today I also started getting "Compilers auto-detection" window every time I start Code::Blocks, after I tried to add WinARM to the list (which was totally confusing, I couldn't get it to work and in the end went back to using makefiles).

Now I don't want it to use any compiler, but it still asks me every time I open Code::Blocks, no matter which one I set as the default.

So any idea how to get rid of the stupid compiler auto-detection window?

[timojaask]

Answering my own question:
Compiler auto-detection window stopped appearing after I removed my custom compiler from "Settings" -> "Compiler and debugger settings".

[oBFusCATed]

What happens if you add it again?
What is the version of C::B?

[timojaask]

My bad, I forgot to mention it - the C::B version that I'm using is Windows nightly build 7452, I'm running Win7 64.
I just tried to re-add the WinARM compiler, but the compiler auto-detection window didn't appear anymore, so I couldn't reproduce the bug. Sorry.

[tigerbeard]

1) How do I hide unused compilers from the dropdown list... (I find it massively annoying have to go through 20+ entries with only 2 compilers installed)

I am sorry that this is not a solution, but at least an explanation. Maybe helping someone to take another step forward  on this.

The compilers are defined by several things
* hard coded classes. They are added in the file

Code Select Expand

source/plugins/compilerhcc/compilergcc.cpp in the class 

Code Select Expand

compilergcGCC in the method

Code Select Expand

compilergcGCC::DoRegisterCompilers. This adds the following hard coded classes to a CompoilerFactoryArray: MSVC/MSVC8/MSVC10/OW/CYGWIN/LCC/KeilC51/KeilCX51/IAR8051/IAR-ARM/ICC/GDC/GNUFortran/G95. Some are only added on Windows systems.
* global XML list.
* user XML list
All these are added to the compiler list used to display in the Settings/Compiler dialog and also in a dialog used to select the default compiler on program start. The global and user XML list are both part of the "default.conf", the users profile file which is a big XML list. In Windows in user/AppData/Roaming/CodeBlocks and in Linux .config/codeblocks.

Also The hardcoded compilers have named XML files in the program directory in the Compliler Plugin (as Zipfile in the Windows installations in the plugins folder). Thats the reason that deleting the XML sections in the default.conf files does not really help. It does help, to delete any user defined compiler data, because thats the only place where user defined compiler data is stored.
But the annoying part of the list are the predefined compilers and they are defined in the default.conf list, the hardcoded classes and the XML data in the plugin- Zip file.

So there are only two ways to get rid of the long list
a) remove the hardcoded items in the code and recompile the source.
b) remove (or move) the XML files in the compiler plugin. This will only shorten a few (XML generated) compilers from the list but it will pop up error messages for each hardcoded compiler. I think by only removing those not producing an error, the list can be shortened without error messages. By removing all except the used compiler XMLs in Windows I could bring the list down to a lengh that the scroll bar disappeared which would be a help already. But I am not sure if that its possible without error pop-ups, but it might - did not try.

Looking at the code, I can not really understand why those compilers were hardcoded. The code for reading compilers from XML is fully there and some compilers are read from XML lists already. To move the hardcoded class data (which is mostly empty anyway) to an own XML that is kept with the compiler plugin ZIP file would be much more flexible and easier. That might even be possible without a lot of redesign beside defining the file and moving the data.
In that case any advanced user can got into the plugin and delete compilers that surely will never ever by used from the list altogether.
However, there might be good arguments for this hardcoded apporach which I am not aware. Some of the regulars might be able to judge better.


Better of course would be a compiler management dialog to enable/disable/copy/duplicate/rename compilers but that obviously is quite a massive undertaking for little effect.


However, may this help anyone who is able to compile CodeBlocks to get some relief for item 1).

[tigerbeard]

Short Update:

its possible to get down to 16 compilers in the list by deleting XML files from the compiler.zip file in the program directory. without causing errors. On my Win7 machine this removes the slider of the drop down field.

Codeblocks/share/CodeBlcosk/compilers

• remove all compoilers except: complier_null.xml
• remove all options excpt the following

options_cygwin.xml
// similar for the following
g95
gcc
gdc
gfortran
IAR8051
IAR-ARM
icc
KeilC51
KeilCX51
LCC
MSVC8
MSVC10
MSVCTK
null
OW

I did not remove them but created a subfolder "park" to park them in there. Worked fine.