XML based compilers

[Alpha]

Maybe we can do it even easier: Reset calls ResetPrivate() which is the virtual method you need to override if you need to do something special and in its default implementation it does nothing (same for LoadXXX). This way, compilers were "forced" to use the default "Reset" (which is good I think) but still can do something special. To soften the requirements we could stick with the virtual Reset method. Although it would be not too bad to make Reset even non-virtual and protected in that case.

What do you think?

Almost everything I know about program design has been self taught through a combination of the internet, and half-finished books; I do not think I know what is the best option here.
Perhaps other developers would like to weigh in?

For the record: Applies flawlessly in the branch. Nice!

Go WinMerge!

When running with debug log (and therefore warnings) enabled, now I get tons of warnings, that the command issued to detect the compiler could not be executed.

Oops... I will deal with that.

[Alpha]

Quick update (nothing big):

• Remove failed execution warnings
• Fix pre-loading of paths on start up (for executable testing)

[Alpha]

Adding to the previous patch:

• Scan and dynamically load pure XML compilers
• Implemented some auto-detection routines (all contained in compilerXML.cpp, but they can later be migrated if that is decided)
• (Initial XML files for) LLVM Clang compiler (as a test case for pure XML compilers)

(Unrelated, but...)

Code: [Select]

Index: src/sdk/resources/editor_configuration.xrc
===================================================================
--- src/sdk/resources/editor_configuration.xrc (revision 8138)
+++ src/sdk/resources/editor_configuration.xrc (working copy)
@@ -465,7 +465,7 @@
                                 <flag>wxALL|wxEXPAND|wxALIGN_LEFT|wxALIGN_TOP</flag>
                                 <border>4</border>
                               </object>
-                              <label>Colouring andf highlighting options</label>
+                              <label>Colouring and highlighting options</label>
                               <orient>wxVERTICAL</orient>
                             </object>
                             <flag>wxALL|wxEXPAND|wxALIGN_LEFT|wxALIGN_TOP</flag>


[MortenMacFly]

Adding to the previous patch:
[...]

Nice, especially the "welcome" of the XML compiler.

BTW: Something that came into my mind: Did you try what happens if you create a copy of a compiler? Dos that still work? I'll try though... I am working with it permanently and so far I see no regressions... Just to let you know that I am not doing "nothing".

Generally @all: Did anybody already try this branch on Linux?

[MortenMacFly]

Looks good so far, I got a question: What Clang compiler do you use? Is there a specific one you use under Windows? (A distro?!)

Also, I've attached another compiler I found in my local copy. Its a specific Fortran compiler, but untested - that's why it is not committed. It should work though, I got this ones from "darmar" - the author of the FortranProjectPlugin. Do you have an easy way/tool to convert/add this? Or do I have to do it the monkey way?

[Alpha]

I use a (slightly old) self compiled version of Clang from their trunk.  The Clang compiler I wrote has only been lightly tested (much if it is written based on pure documentation), so beware of errors.

Do you have an easy way/tool to convert/add this?

The absolute easiest way is to register it in compilergcc.cpp as a normal compiler, then (build and) launch Code::Blocks, open the compiler settings, create (and delete) a new flag for the compiler (to make it think it has changed), and click OK.  This will generate a fully usable file in your user data folder.
However, I usually uses my ListToolbox plugin, because with it, I can make the output look much nicer.  (Using ListToolbox takes about equivalent effort as formatting one of each type of entry because of the way it chains commands.)
However (2), you could just apply this patch (it also contains a fix for the loading of copied compilers whose flags have been changed, and slightly more along the lines of auto-detection routines for pure XML compilers).

Did you try what happens if you create a copy of a compiler? Dos that still work?

It does work except that copied compilers do not load user customized sets of compiler flags; this fixes it.

[MortenMacFly]

It does work except that copied compilers do not load user customized sets of compiler flags; this fixes it.

So... to summarise: It works pretty well and I don't see major drawbacks. It only needs testing on Linux.

What do you think is missing?

[Alpha]

I would like to finish registry support and a couple other tweaks for pure XML compilers.  I also want to allow compilers to specify a 'weight' - which would be used to decide what order to display them in.  There are also some compilers with relatively uncomplicated auto-detect that I think can be swapped for pure XML.

From my perspective: Linux testing, and auto-detect testing (after I rewrite to XML the compilers I can).

[jens]

From my perspective: Linux testing,

I just committed fixes to the linux project-file and the automake-system.

It's compilable and seems to work:
I used C::B compiled with automake to compile C::B with C::B and run it from inside C::B.

..., but I did no deeper testing.

[Alpha]

This patch completes the remaining features I currently have planned:

• Compiler weight
• Dynamic tooltip for auto-detect compilers dialog
• More XML compiler auto-detection routines
• Converted some compilers (the easy ones) to pure XML (to anyone who uses any of the following: please test to ensure auto-detection works at least as good as before)
  
  • Digital Mars Compiler
  • LLVM D Compiler
  • GNU GCC Compiler for MSP430
  • PGI Fortran Compiler
  • GNU GCC Compiler for PowerPC
  • Small Device C Compiler
  • Tiny C Compiler
  • GNU GCC Compiler for TriCore

I would recommend that testers delete their current default.conf (or launch Code::Blocks with a new profile) because this branch does make a few (minor) changes to how the compilers save (which may, or may not interfere).

I just committed fixes to the linux project-file and the automake-system.

Sorry, I think this brakes the build system again.

[jens]

I just committed fixes to the linux project-file and the automake-system.

Sorry, I think this brakes the build system again.

No problem !

@MortenMacFly:
Should I do the linux fixes, or are you already working on it ?

Should be trivial, just deleting some files from src/plugins/compilergcc/Makefile.am and fixing the project-file for linux.
The new xml-files are handled automatically as long as they are in src/plugins/compilergcc/resources/compilers/ .

[Alpha]

Maybe this is a slightly tidier way to fix PCH for compilerXML.cpp:

Code: [Select]

Index: src/plugins/compilergcc/compilerXML.h
===================================================================
--- src/plugins/compilergcc/compilerXML.h (revision 8155)
+++ src/plugins/compilergcc/compilerXML.h (working copy)
@@ -3,7 +3,7 @@
 
 #include <compiler.h>
 
-#include <wx/string.h>
+class wxString;
 
 class CompilerXML : public Compiler
 {
@@ -28,7 +28,7 @@
             none
         };
 
-        bool AddPath(const wxString& pth, int sm, int rmDirs = 0);
+        bool AddPath(const wxString& pth, SearchMode sm, int rmDirs = 0);
 
         wxString m_fileName;
 };
Index: src/plugins/compilergcc/compilerXML.cpp
===================================================================
--- src/plugins/compilergcc/compilerXML.cpp (revision 8155)
+++ src/plugins/compilergcc/compilerXML.cpp (working copy)
@@ -1,10 +1,12 @@
 #include <sdk.h>
 
-#include <wx/arrstr.h>
-#include <wx/filefn.h>
-#include <wx/regex.h>
+#ifndef CB_PRECOMP
+    #include <wx/arrstr.h>
+    #include <wx/filefn.h>
+    #include <wx/regex.h>
+    #include <wx/xml/xml.h>
+#endif // CB_PRECOMP
 #include <wx/textfile.h>
-#include <wx/xml/xml.h>
 #ifdef __WXMSW__ // for wxRegKey
     #include <wx/msw/registry.h>
 #endif // __WXMSW__
@@ -243,7 +245,7 @@
     return adrGuessed;
 }
 
-bool CompilerXML::AddPath(const wxString& pth, int sm, int rmDirs)
+bool CompilerXML::AddPath(const wxString& pth, SearchMode sm, int rmDirs)
 {
     wxFileName fn(pth + wxFILE_SEP_PATH);
     fn.Normalize(wxPATH_NORM_ENV_VARS|wxPATH_NORM_DOTS);


[MortenMacFly]

Maybe this is a slightly tidier way to fix PCH for compilerXML.cpp:

Code: [Select]

-#include <wx/string.h>
+class wxString;
[...]
         wxString m_fileName;


That is wrong. You cannot use a fwd decl if you are using  an instance of wxString. Its only valid when using only const refs or pointers.

Code: [Select]

Index: src/plugins/compilergcc/compilerXML.cpp
===================================================================
--- src/plugins/compilergcc/compilerXML.cpp (revision 8155)
+++ src/plugins/compilergcc/compilerXML.cpp (working copy)
@@ -1,10 +1,12 @@
 #include <sdk.h>
 
-#include <wx/arrstr.h>
-#include <wx/filefn.h>
-#include <wx/regex.h>
+#ifndef CB_PRECOMP
+    #include <wx/arrstr.h>
+    #include <wx/filefn.h>
+    #include <wx/regex.h>
+    #include <wx/xml/xml.h>
+#endif // CB_PRECOMP
 #include <wx/textfile.h>
-#include <wx/xml/xml.h>
 #ifdef __WXMSW__ // for wxRegKey
     #include <wx/msw/registry.h>
 #endif // __WXMSW__
@@ -243,7 +245,7 @@
     return adrGuessed;
 }
 
-bool CompilerXML::AddPath(const wxString& pth, int sm, int rmDirs)
+bool CompilerXML::AddPath(const wxString& pth, SearchMode sm, int rmDirs)
 {
     wxFileName fn(pth + wxFILE_SEP_PATH);
     fn.Normalize(wxPATH_NORM_ENV_VARS|wxPATH_NORM_DOTS);


...although this is correct. :-)

Will do.

Should I do the linux fixes, or are you already working on it ?

I would prefer you do it. for me it would be a "Blindflug" as I am not under Linux.

[oBFusCATed]

Its only valid when using only const refs or pointers.

Partially true, because normal (non-const) references are forward declarable, too.

[jens]

Should I do the linux fixes, or are you already working on it ?

I would prefer you do it. for me it would be a "Blindflug" as I am not under Linux.

Already done.