Author Topic: Compiler list...  (Read 7933 times)

Offline commontater

  • Single posting newcomer
  • *
  • Posts: 2
Compiler list...
« on: May 09, 2011, 08:33:41 am »
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?


Offline gd_on

  • Lives here!
  • ****
  • Posts: 796
Re: Compiler list...
« Reply #1 on: May 09, 2011, 06:59:39 pm »
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
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline commontater

  • Single posting newcomer
  • *
  • Posts: 2
Re: Compiler list...
« Reply #2 on: May 09, 2011, 07:14:19 pm »
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!

Quote
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.

Online stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: Compiler list...
« Reply #3 on: May 09, 2011, 07:25:38 pm »
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.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline timojaask

  • Single posting newcomer
  • *
  • Posts: 4
Re: Compiler list...
« Reply #4 on: October 19, 2011, 09:17:22 am »
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?

Offline timojaask

  • Single posting newcomer
  • *
  • Posts: 4
Re: Compiler list...
« Reply #5 on: October 19, 2011, 12:21:24 pm »
Answering my own question:
Compiler auto-detection window stopped appearing after I removed my custom compiler from "Settings" -> "Compiler and debugger settings".

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Compiler list...
« Reply #6 on: October 19, 2011, 12:50:09 pm »
What happens if you add it again?
What is the version of C::B?
(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 timojaask

  • Single posting newcomer
  • *
  • Posts: 4
Re: Compiler list...
« Reply #7 on: October 20, 2011, 07:57:21 am »
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.

Offline tigerbeard

  • Almost regular
  • **
  • Posts: 186
Re: Compiler list...
« Reply #8 on: January 06, 2021, 09:03:03 pm »
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
source/plugins/compilerhcc/compilergcc.cpp
in the class 
Code
compilergcGCC
in the method
Code
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).



Offline tigerbeard

  • Almost regular
  • **
  • Posts: 186
Re: Compiler list...
« Reply #9 on: January 06, 2021, 09:24:18 pm »
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.