Compiler Index versus ID

[MortenMacFly]

Dear all,
after a break I came back and wow! Many amazing changes in C::B. One thing is the addition of the D compiler... great!
Hence I've got a question: I have added the G77 and GCC 4.10 compiler to C::B by simply adjusting a copy of the GCC compiler. Quite some of my projects depend on these compilers. Now we've had that discussion already but I would like to ask again: Isn't it possible to use a compiler ID and not an index for the compiler setup in the project files? It's kind of annoying to use a search & replace with the project files which I've done quite some time now. This doesn't fit to all the features C::B offers.
I believe this is for sure already in the pipeline for the compiler framework re-design but I'd like to vote for doing this small (?) change now: I am thinking of simply replacing the index (e.g. "1") with the string like the compiler is represented in the compiler setup (e.g. "GNU GCC setup". This would not change the file format of the project files in general but would work (imho) much better.
...or is this really a major change?
Morten.

[killerbot]

I already posted a patch for this some time ago, which seperated internal compilers from user compilers. So internal and external compilers can't fight any longer. But indeed we need to go one step further.
I'll try to update the patch this evening (bringing it back in sync with todays revision).

The only conflict that can remain is when you remove a user compiler and add another one, then they all shift one up, so their (ID/index) changes.

This is the 'outdated' :-( patch :
http://sourceforge.net/tracker/index.php?func=detail&aid=1389603&group_id=126998&atid=707418
And this is what I have implemented in it.
http://forums.codeblocks.org/index.php?topic=1741.0


Cheers,
Lieven

[MortenMacFly]

I already posted a patch for this some time ago, [...]

Sounds interesting to me. I'll have a look at it later - maybe I can get it to work with SVN-HEAD...
Morten.

[killerbot]

enjoy it, any ideas let me know. During my update to head, I will go all the way now, discussed it with Yiannis. So we are going for unique ID now, not even a number anymore ....
I hope to have it ready as soon as possible, will divide my time between CB and helping out my girlfriend with Mambo.   

[takeshimiya]

If this makes it, can the lexers be indexed by a string instead of an ID also?

[MortenMacFly]

If this makes it, can the lexers be indexed by a string instead of an ID also?

That's actually exactly my suggestion. For me an "ID" is a mixture of numbers and characters... ;-)

Anyway, I've had a look at killerbots' changes. It's quite a big patch but I guess I understood what's going on. I like the way he replaced the "direct indexing" with methods "Get/SetCompiler(By)Id". Thus the ID can be anything and still (if required) the old index to be backward compatible. Looks good to me, it's extensible and flexible.
I'm still trying to apply the path to the current SVN head but there have been really massive changes meanwhile... I guess when I've finished it won't work... A pity that it hasn't been applied any time earlier...

Morten.

[MortenMacFly]

Replying to myself... :lol:

I just wanted to say that I have just realised that C::B now supports compiler ID's!!! That's absolutley fantastic!!! And I am not gonna tell you that I was still about to apply the patch of killerbot to my latest SVN version... You guys are too fast for me... that makes me feel small... :lol:

But honestly: A very BIG thank you ever so much!

Morten.

[yop]

So GetCompilerIndex() has been replaced by GetCompilerID() and I can use CompilerFactory::GetCompiler(CompilerID) instead of CompilerFactory::Compilers[CompilerIndex] (this wasn't good at all but I was using it ? In general should I consider compiler index obsolete?

[mandrav]

In short, yes.

GetCompilerIndex() is left there for accessing the compilers by an index number. But this is only for compiler selection comboboxes etc.
In regular code, compilers should be accessed by ID. This is an automatically set string uniquely identifying each compiler. This doesn't ever change.