AutoDetect Yagarto?

[dasfoo]

Two Questions (meaning three or more)

1) I beleive that the Yagarto tool-chain isn't auto detected and setup by code blocks.  Is this true?

http://www.yagarto.de/

Yagarto being a pre-built tool chain for ARM that installs under Windows (only).

2a) Looking at the code I think I could probably make that happen if there is any interest.  I think for embedded people to have Yargarto and Code Blocks work together would be a big win.

2b) I notice that Yargarto puts it's path info in the the windows registry when it's installed, would it be okay for the auto detect function to look in the registry?

3) Looking over the code for detecting and setting up various compilers it looks to me like compiler detect and configuration  could be re-factored such that the compiler definitions and setup would be defined in an external config file.  Might make it easier for other compilers to be added.
 

[ollydbg]

3) Looking over the code for detecting and setting up various compilers it looks to me like compiler detect and configuration  could be re-factored such that the compiler definitions and setup would be defined in an external config file.  Might make it easier for other compilers to be added.

Yes, sounds reasonable, and great idea.!!!

currently, all the compiler search(Windows) is just like search the key path in the register or check the key file exist in some fixed place.

[dasfoo]

3) Looking over the code for detecting and setting up various compilers it looks to me like compiler detect and configuration  could be re-factored such that the compiler definitions and setup would be defined in an external config file.  Might make it easier for other compilers to be added.

Yes, sounds reasonable, and great idea.!!!

currently, all the compiler search(Windows) is just like search the key path in the register or check the key file exist in some fixed place.

Well okay then.  I'll see what I can get done in my copious spare time.  For me first order of business is to build codeblocks from source, then hack in support for Yargarto with the compiler options defined in a config file instead of hard coded. 

Questions:

Does CodeBlocks have a preferred data format for config files, AKA something like xml or yaml. 

I'm thinking each compiler should have it's own configuration file.

[ollydbg]

Well okay then.  I'll see what I can get done in my copious spare time.  For me first order of business is to build codeblocks from source, then hack in support for Yargarto with the compiler options defined in a config file instead of hard coded. 

Questions:

Does CodeBlocks have a preferred data format for config files, AKA something like xml or yaml. 

I'm thinking each compiler should have it's own configuration file.

nice to hear.

Codeblocks use xml format (*.cbp, *.conf are all actually xml files), if you download the source code, you will find a Tinyxml library included in the source.

[dasfoo]

Well poking at things a bit was able to install the nightly and build code blocks from sources. And compile a hello world program seems to work.

Is a start.

Well that wasn't too hard.  Seems to auto detect Yagarto Now...  Now see if works.  It looks like the GNU ARM Compiler is oldish.  The executables were arm-elf- instead of arm-none-eabi- might mean that some of the compiler settings aren't up to date

[Folco]

3) Looking over the code for detecting and setting up various compilers it looks to me like compiler detect and configuration  could be re-factored such that the compiler definitions and setup would be defined in an external config file.  Might make it easier for other compilers to be added.

Great idea ! I could use my favourite 68000 toolchain inside C::B

[MortenMacFly]

3) Looking over the code for detecting and setting up various compilers it looks to me like compiler detect and configuration  could be re-factored such that the compiler definitions and setup would be defined in an external config file.  Might make it easier for other compilers to be added.

I don't think this makes sense for two reasons:

1.) The configuration is already in XML -> in the *.conf file of Code::Blocks.
2.) Code::Blocks allows to modify every setting of a compiled through the UI of the compiler setup. In addition it allows making copies of existent compilers and change every value possible.

So I don't see how and why external config files will makes things easier...?! It would only enable to edit in a file what you can easily configure via an UI interface...?! In addition you can already edit everything in the config file of Code::Blocks if you really wanted to. But I doubt this will make things easier and especially less error-prone.

[dasfoo]

1.) The configuration is already in XML -> in the *.conf file of Code::Blocks.
2.) Code::Blocks allows to modify every setting of a compiled through the UI of the compiler setup. In addition it allows making copies of existent compilers and change every value possible.

So I don't see how and why external config files will makes things easier...?! It would only enable to edit in a file what you can easily configure via an UI interface...?! In addition you can already edit everything in the config file of Code::Blocks if you really wanted to. But I doubt this will make things easier and especially less error-prone.

I think what you're thinking is slightly different that what I meant. (I could be just confused)

Looking at the compilergcc plug-in there are over twenty modules to detect and define the compiler options one for each compiler. 

compilerGNUARM, compilerGNUAVR, compilerMSVC, compilerMSVC8, compilerMSVC10, compilerBCC, compilerDMC, compilerOW, compilerGNUARM, compilerGNUAVR, compilerGNUMSP430, compilerCYGWIN, compilerLCC, compilerYagarto, etc etc.

The code in each module looks pretty much the same duplicated over and over with small improvements in the more recent modules.  And things looking kind of stale in others. The main differences are the executable names, compiler and linker options, with a few tweaks for detecting different compilers installed along with code blocks and or not in the path.  Seems to me that the executable names and compiler options should be defined in xml files, and the the modules for detecting the compilers rolled into a single module, say compilerStdGcc.  With nothing preventing you from doing it the old way if needed.

That would make it much easier to add a new compiler or an updated one because 95% of the time all you'd just cut and paste new xml file.  Or add another compiler definition to an existing one.