XML based compilers

[Alpha]

OK, compilers can now save their flags back into an XML file.

My current idea is to have a right-click menu with:

Code

New flag...
Modify flag...
Delete flag

I can create this menu, but I am not certain how I am supposed to attach it.  The popup will belong to a wxCheckListBox (XRCID: "lstCompilerOptions").  Does the connection belong in an event table?  Should I be calling Connect()?  (Also, is this the suggested way to use it?)
The only wxWidgets events I have created before were automatic wxSmith generated ones, so if anyone could point me to the relevant section of documentation/give me a hint, I would be much obliged.

[Alpha]

I have run into even more event related woes, and will be asking some questions in the wxWidgets forum.  So, it may be some time before any more progress is shown here.

[thomas]

I think Scrat would be another option for a replacement of SQPlus.

Sqrat looks nice, it's very straightforward to use, feature-complete, header-only.

That said, I've invested some time today trying it out, and as nice as it is on paper, it crashes even on the simplest possible test case (bind 1 function, compile a 1-line script). Basically the same example like on their website, only even simpler.

Running single-step shows a segfault in sqratScript.h, line 54.

Thing is, the sq tool from the same, identical build works just fine. So I guess it's not something wrong with the Squirrel build, it must really be Sqrat

If you want to waste some time in the evening playing with it, I can share the project. Maybe I'm only just too stupid, and you can figure it out.

[Alpha]

Completed patch finally available.  I would assume there are multiple bugs in it that are yet to be found (after all, what is testing for?), but I think it contains a useful set of features.

I will write up some documentation on the XML format soon.

[Alpha]

Preliminary documentation is done.

I have begun work on a loader for generic "pure" XML compilers.

Completed patch finally available.

I forgot to mention; this patch includes:

• XML based compiler options (of course)
• Warning messages if multiple compiler options are unwise to use together (but still legal)
• Automatic disabling of conflicting compiler options (for example, enabling debug symbols automatically disables strip)
• Options to edit, add, and remove compiler flags through the GUI (plus a compact dialog for modifying flags)
• Compiler options are saved back to XML if they are modified (in <user_data>/CodeBlocks/compilers)

[MortenMacFly]

If you want to waste some time in the evening playing with it, I can share the project. Maybe I'm only just too stupid, and you can figure it out.

To be honest I never tried myself, just found this link when looking for a more up-to-date SQPlus. So sure, gimme gimme... (I am back btw...).

And btw:

Well, if nothing helps, we can still move back to Angelscript, which is well supported. Ironically, the reason why we abandoned Angelscript back then was that it didn't do 64 bits at that time...  

This is really fun and honestly I don't get it: Did we ever try 64 bit with scripting at that time seriously? Because then we would have found out easily that we are doomed with SQPlus. I wonder if it is working straight forward on Linux though... on Windows its very bad and it gets even worse as new (more strict) compilers hit the floor.

Having said that, returning to AngelScript is also not that easy: For example, all the script binding would need to be re-done....

[MortenMacFly]

Preliminary documentation is done.

Huh - the first pach provider with a documentation! That's Wohooo! ;-)

BTW: I have tried the patch before the last one during the time I was off - this already seems to work quite well. I didn't find any serious show-stoppers. I'll try version the next days...

Some comments I do have:

1.) I changed the log messages when the XML file cannot be found or alike to cbMessageBoxes. Because if tat happens the compiler is in an "undefined" state and you cannot use it. Newbies won't realise that and otherwise our forums get flooded with such requests. Maybe we should even disable this particular compiler in such a case. But disabling compilers hasn't an API so far IMHO...

2.) I think later on we can/should transfer the regexes and advanced compiler options to the XML file, too. For this, it needs an interface to the configmanager.

[MortenMacFly]

...I just saw: Did you realise SVN revision 8060? Is this already integrated? Its not a very wise thing to change the compilers at the moment in SVN. Maybe we should lock the plugin for a while...

[thomas]

Sqrat test attached, no external dependencies. Unzip, doubleclick, hit "build".

Builds the libs, the sq interpreter, and a test program which installs error handlers, binds one function, and compiles a 1-line script that calls this function (which is enough to crash).

[attachment deleted by admin]

[killerbot]

I added some compiler options, wouldn't lock it at this moment. Important for adding  C++11 related ones.

A for showing message boxes, ensure they don't end up to much during project loading and building. Eg project building for several compilers, but then you use it on a system where some compiler is not present ==> should just be mentioned in text in the build log (as it is now), no message boxes, otherwise automated building is broken.

[MortenMacFly]

Sqrat test attached, no external dependencies. Unzip, doubleclick, hit "build".

Same crash here, it seems the VM pointer is zero, therefore compilation fails and throws (in sq_compile)...

[MortenMacFly]

Sqrat test attached, no external dependencies. Unzip, doubleclick, hit "build".

Same crash here, it seems the VM pointer is zero, therefore compilation fails and throws (in sq_compile)...

Harhar, funny. Solved it. All you need to do is to set the default VM before you do the table stuff (all what's in your "try..." statements. So just add this line after "sq_seterrorhandler(vm);":

Code

Sqrat::DefaultVM::Set(vm);

Then it works just fine. (Its written in the docs, too btw... )

[thomas]

Wow, what a stupid mistake (the actual mistake was forgetting to pass the VM parameter to the script constructor, though). Hmm good job you can actually make that mistake and it doesn't warn you... but at leat it crashes hard and crashes early, so I guess that's fair enough.

Setting the default VM fixes the issue too, of course, and then you need not pass the VM to the table's constructor or the root-table getter, either. Maybe that's even better, we probably don't want more than one VM in Code::Blocks anyway, do we.

So it works... guess then it should be no biggie to get this running. If I'm not too tired on saturday afternoon, I might just give it a try.

[Alpha]

2.) I think later on we can/should transfer the regexes and advanced compiler options to the XML file, too. For this, it needs an interface to the configmanager.

What are these other advanced compiler options?  I think the XML files currently contain all options except for the regexes.
The options_*.xml files currently only contain settings that could be losslessly transferred from C++.  Looking at the various settings each compiler contains, it appears that regexes are the only remaining items that fit this requirement; the next patch will support these in the options files.
The other main component of a compiler is auto-detect.  I will be creating some (limited) functionality of this in compiler_*.xml files (files I am working on for dynamically detected pure XML compilers).

...I just saw: Did you realise SVN revision 8060? Is this already integrated?

Yes (and it was very fast to do; adding this new flag to options_common_warnings.xml put it in the whole GNU family).

About message boxes/error handling, what I have written so far mostly makes the (incorrect) assumption that it will only be fed properly formed files.  Eventually something more robust will need to be added...

• Warning messages if multiple compiler options are unwise to use together (but still legal)
• Automatic disabling of conflicting compiler options (for example, enabling debug symbols automatically disables strip)

(I am no compiler expert, so I only added these interactions where they were obvious.  Feel free to let me know of any flag interactions I have missed/messed up.)

Question: The only condition that <if></if> blocks currently recognize is platform - are there any other conditions that would be made use of during the loading of a compiler?

[MortenMacFly]

What are these other advanced compiler options?

They are for example in default.conf:
<compiler> -> <sets> -> <{compiler's name}> -> <macros>
...and contain everything you setup in the compiler options page under -> Settings -> Compiler -> tab "Other settings" -> Advanced options -> {tabs "Commands", "Output parsing", "Others"}.

Note that this is usually empty, if not changed. You can apply what's written here:
http://wiki.codeblocks.org/index.php?title=Adding_support_for_non_C/C%2B%2B_files_to_the_build_system
...to see any content there.