Author Topic: Patch for internal/user compiler conflicts  (Read 6959 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5506
Patch for internal/user compiler conflicts
« on: December 24, 2005, 05:17:41 pm »
Description of the basic problem :

Today we have for example 8 internal compilers, they are stored in the compiler array at indexes 0, 1, ..., 7. Say we create a user compiler, that one also gets added to the compiler array : at index 8.
The cbp files specify for the projects/targets the compiler to use by means of that index !!!! (this is THE problem).
So when we have a project using 'our user' compiler the cbp file will specify it like this :
<option compiler="8">.
Note : compilers also have ID's : internal compilers [1..255], user compilers [256...]. These ID's are visible in the default.conf like
<Set001>, <set002>, ... <set008>, <set256>.

Now assume we get a new version of CB where a new internal compiler has been added => internal compilers are in the array (oh yes, that's the array of the CompilerFactoy) now at indexes 0, 1, .., 7, 8, and 'our user' compilers is now at index 9.
So if we load our project again it still is connected to the compiler at index 8, but that is no longer the compiler it was supposed to use !!!!

It is ovbious that not the index should have been used for specifying which compiler to use for a project/target (Suppose we don't use an array anymore but some hash table, --> index ???), so we got an implementation dependency here. :-(

What should we do the : specify an unique compiler ID in the project/target specifications. Probably an unique string representation is best ?

To be at least somewhat backwards compatible it did not went all the way yet (so no string id or the like), I used the compiler id (see remark 1 below), but therefor to allow <option compiler="0"> the "0" should be a valid ID --> compiler ID's now start from 0 instead of 1 :
  ===> internal compilers [0, .. , 254] , user compilers [255, ...]
In the default.conf the sets are still written out as before so compiler with ID i shows up as i+1 in the default.conf,
examples :
  ID 0 --> <set001>
  ID 255 -> <set256>

So I had to change in total 32 source files to start working with ID's and no longer index, so several functions who were named like :
GetCompilerIndex became like GetCompilerId. Also the compiler array of the CompilerFactory is no longer public, which led to high coupling in the past since compilers were accessed like CompilerFactory::compilers[use_that_damn_index], now you get access by 2 methods like :
Why 2 methods ? Well there are 2 kind of users of this code :
 1) example : project -> get associated compiler -> project has a connection with the ID -> so get it by id
 2) does who want all compilers to list them (most by name) in a selection list (note : in the future it might b better to provide iterators access for that, or even retrieve the list of names by a method call to the CompilerFactoy, or let the CompilerFactory manage selection list (and GUI?)). -> loop over the amount of compilers and for each do get by index (otherwise do NOT use that fucntion)
Provided are also 2 converter functions :
  - index --> Id
  - Id --> index
So if a selection was made out of those list of compilers, you get back an index from the selection control, so that index needs to be translated into an ID to continue to work with it. The opposite translation is used to set a default selection in a selection list (default compiler -> ID -> index in the selection list)
Note : once some unique string ID's would be issued this might become even more cleaner and strict.

Limitations of the fix :
Allthough this fix already solves the issue of conflicts between the internal and user compilers it still has left some problems unresolved. In the default.conf, there are <setABC> but that ABC is not read out to give the Id to the compiler. The compiler id's are handed out based upon the order of those sets in the default.conf. Say we had 3 user compilers -> set : 256, 257, 258, and ID's get handed out like 255, 256, 257.
Say we delete the second user compiler -> next time the ID's will be 255, 256 (and the sets pobably get to be 256, 257) so also in this case the project/target linked to ID 256 is suddenly linked to another compiler, and the project/target linked to ID 257 is now linked to ... ???
So don't delete user compilers unless you are aware of these kind of things (those problems already arised with the index way also).

So more work is in the pipeline here, but for the moment people using user compilers won't get broken when new internal compilers are added(the more the better ;-) ).
To solve the problem completely I am afraid there will be a break towards cbp files since
<option compiler="Mingw"> is not really the same as <option compiler="0">, we could parse for both (but then only for the internal compilers, since there we know what those numbers stood for, and CB can adjust the cbp file accordingly). But that's another discussion requiring some more research.

kind regards,

patch is at :

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Patch for internal/user compiler conflicts
« Reply #1 on: December 24, 2005, 06:47:42 pm »

Just a suggestion. It should not be better to separate internal and user compilers? For example one map for the first and another map for the latter. IMHO this could help to prevent some conflicts.

Best wishes,

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Patch for internal/user compiler conflicts
« Reply #2 on: January 02, 2006, 11:16:46 pm »
Shouldn't would put the custom patch stuff on the wiki, stuff tends to be barried pretty quickly on the forum?

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5506
Re: Patch for internal/user compiler conflicts
« Reply #3 on: January 02, 2006, 11:22:35 pm »
patches are at sourceforge page, and when more of us starte using
this -->  :

might help,