XML based compilers

[Alpha]

This patch should (I cannot be certain, because I only tested it on Windows):

• Read projects and default.conf entries containing compiler id's in the old format (and upgrade it to the new format)
• Fix regexes (for some reason -dumpversion gives all three values on my computer?!) to only look for major.minor (all compiler flags in the trunk already exist in this branch; these fixed regexes should prevent them from incorrectly being hidden)
• Fix bug when copying a compiler (copied compilers are supposed to be placed at the end of the list, however, my initial implementation of weight sorted compiler order neglected to take this into account)
• Add "Enable non-platform compilers" check-box (to load, for example, MSVC on Linux; be warned that as I am not on Linux, I cannot tell if this actually works)
• Switch the right-click note to a tool tip (this is less obtrusive, but should still alert the user to the editing capability)

Copied pure XML compilers currently act exactly like copied built-in compilers (or at least, they are supposed to).  The compiler_*.xml files are never duplicated, however, the user data folder is scanned for them in case the user created a local compiler.
In the future, I may create a wizard to allow for (semi-)graphical creation of a fully fledged (XML) compiler (assuming there is any interest in such a feature).

[MortenMacFly]

This patch should (I cannot be certain, because I only tested it on Windows): [...]

Thanks for the fast response! I had a a look into it and I see this snippet in compiler.cpp (and compilerfactory.cpp):
     {
        tmp.Replace(wxT("-"), wxEmptyString); // try again using previous id format
        if (!cfg->Exists(tmp + _T("/name")))
            return;
    }
Didn't you mean to replace "_" (underscore) with "" (empty)? Here, you replace "-" (minus), but IMHO that id not present in the IDs anyways...?! (See my previous post about the ID's). Why do you do so?

[killerbot]

build is broken :

Code

AutoDetectResult CompilerLCC::AutoDetectInstallationDir()
{
#ifdef __WXMSW__

...

    wxString compiler; compiler << wxFILE_SEP_PATH << _T("bin") << wxFILE_SEP_PATH << m_Programs.C;

...


#endif // __WXMSW__

...

    return wxFileExists(m_MasterPath+compiler) ? adrDetected : adrGuessed;

==> on linux : compiler does NOT exist, since declared in the ifdef part !!!

[MortenMacFly]

build is broken :

Try again after SVN update.

[Jenna]

Another build fix is in svn (missing symbols in libcompiler.so).

The checkbox to allow non-platform compilers needs a restart to have an effect.
This should be stated in the label, or if possible the compiler should be reloaded automatically.

[MortenMacFly]

The checkbox to allow non-platform compilers needs a restart to have an effect.

Maybe to clarify, where this comes from: I recently discussed with Alpha the following:

Something else in between: I read this:
http://www.orbiterwiki.org/wiki/Free_Compiler_Setup_Under_Linux

And I had an idea: Whats missing for the compiler but would really be useful for cross compiling is that you could setup via Config/API (!) if a compiler is attached/active under the current platform. [...]

But yes, the restart should be clarified.
Edit: Done.

[Alpha]

Didn't you mean to replace "_" (underscore) with "" (empty)? Here, you replace "-" (minus), but IMHO that id not present in the IDs anyways...?! (See my previous post about the ID's). Why do you do so?

Although "-" (minus) is valid as an XML element name, TiXml apparently decides that they should be synonymous with, and written as "_" (underscores).  The change I made to the ID creation algorithm allows "-" to be used internally (I mostly did this for the cosmetic purposes of naming the XML files: options_arm-elf-gcc.xml is more recognizable than options_armelfgcc.xml, which is what it would have been under the previous system).

This should be stated in the label, or if possible the compiler should be reloaded automatically.

This patch causes the compilers to be reloaded (if chkNonPlatComp changed) when the settings dialog is dismissed; I did not do this at first because I was worried about possible side effects, however it seemed to function as expected in my few test cases.

(Sorry about the build issues.)

[Jenna]

Applied in the branch, with one little change:
if abuild is active the settings will not be applied, because unloading and loading compilers might lead to problems.

[Alpha]

• Switch the right-click note to a tool tip (this is less obtrusive, but should still alert the user to the editing capability)

By the way, am I correct in assuming the revert of this means that a visible note is preferred over a tool tip?

[killerbot]

when working on the silencing of some warnings, I did the following.

I added for example on the GLOBAL compiler level some directives (-std=c++0x, or -fpremissive, or ...)

Then I rebuild CB with CB, the new directives take effect, but then then generate new unwanted warnings, because then they are also provided to gcc, in case its building c sources (like the depslib), which made me think. Shouldn't those compiler options be categorized (C, C++, both) , and have our system being smart enough that when he sees a C++ directive, but the current project is C, that he does not apply it ?

What do you think ?

[Alpha]

For sorting these flags, I think there are several options:

• Internally maintain a list of which flags should only used during C compilation or only during C++ compilation.  The user interface would look exactly the same, and all known flags (from the internal list) would be automatically sorted behind the scenes.
• Give compiler flags an additional option to categorize themselves as C/C++/both.
• Use one of the above options and add additional sections to the other compiler options and other linker options locations.  This would allow the user to specify their own sorting of flags, however, it would alter the .cbp file-format.
  
  • Alternatively, this same addition to the user interface could be created, but all sorting would be recorded in the type of list mentioned in the first option.  This would not change the .cbp file-format, but the settings would only be saved into the user profile.

My personal preference is the first option.  Which option do you (and anyone else who would like to voice their opinion) recommend I pursue?  (Is there another choice I have not considered yet?)

[killerbot]

option 1 is for sure a start. Might create some maintenance problems, but we could start that way.

[oBFusCATed]

Or the best options (three) - separate the c and c++ compilers in different entries/compilers

[MortenMacFly]

By the way, am I correct in assuming the revert of this means that a visible note is preferred over a tool tip?

For such important things, yes. Most people don'T wait long enough that the tooltip shows. Also, there are platforms where there is no tooltip. So tooltip should really be a "tip", not to worry about if you don't know it.

[MortenMacFly]

Or the best options (three) - separate the c and c++ compilers in different entries/compilers

Why would you do that? MSVC for example is one compiler for all. We shouldn't split up things like that. I think grouping visually is fair enough. And event hat I believe won't be used by most of the people. To be honest to me (and only me) it sounds a bit like an overkill. But maybe just because I fail to see the benefit for me (again: only for me).,