CC makes C::B hang in ExpandBackticks

[MortenMacFly]

BTW: I'm looking why the no-change-build of cb is slow. It turned out that the DirectCommands object is recreated tons of times (takes 30-50% time).

Well it has to at least for each project you compile in the WS for deps (re-)computation, at least. It should instantiate as many times as you have project in your WS. Is that true?

[MortenMacFly]

Why? Duplicating code is never a good thing.

Better solution?

[oBFusCATed]

Well it has to at least for each project you compile in the WS for deps (re-)computation, at least. It should instantiate as many times as you have project in your WS. Is that true?

I think it is created for every file. I have to dig more, but my crashing bug is quite annoying and also the code there is a total mess of spaghetti. There is no way someone to understand or modify it easily.

[MortenMacFly]

also the code there is a total mess of spaghetti. There is no way someone to understand or modify it easily.

Where? Maybe if you tell someone can help...

[oBFusCATed]

Where? Maybe if you tell someone can help...

Look at DoRunQueue and BuildStateMachine, also the DirectCommands class is a bit messy

[Alpha]

Where? Maybe if you tell someone can help...

Look at DoRunQueue and BuildStateMachine, also the DirectCommands class is a bit messy

Tell me about it... .  Every time I tried to modify something in there for the XML compiler branch, I came out with a headache.  I think the only way to make the build mechanism readable would be a complete rewrite of it, but that would be a huge amount of work (which is why I have, for the most part, avoided it).

[MortenMacFly]

Look at DoRunQueue and BuildStateMachine, also the DirectCommands class is a bit messy

Have a look at the attached images... ;-)

Edit: Removed images as they don't seem to help...

[oBFusCATed]

WTF... I doubt it will help...

p.s. I hope you know these images will be deleted some day

[MortenMacFly]

WTF... I doubt it will help...

Sad...

p.s. I hope you know these images will be deleted some day

Did that now.

[oBFusCATed]

Jens: Can you rebuild cb-unix.cpb with c::b compiled and started from another c::b?

[Jenna]

Jens: Can you rebuild cb-unix.cpb with c::b compiled and started from another c::b?

Yes.

[oBFusCATed]

Yes.

Hm, have you modified the project to run cb in a terminal?

[Jenna]

Yes.

Hm, have you modified the project to run cb in a terminal?

I only did it in debug-mode and this works (most of the time) if the ExpandBackticks stuff does not kick in.
But in normal mode it hangs reliably if it tries to build the first target.
With console output enabled it also works.
There are several errors shown before the project is loaded:

Code

execvp(-version) failed with error 2!
execvp(-version) failed with error 2!

(codeblocks:22219): GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `GtkRadioMenuItem'

(codeblocks:22219): Gtk-CRITICAL **: IA__gtk_radio_menu_item_get_group: assertion `GTK_IS_RADIO_MENU_ITEM (radio_menu_item)' failed

(codeblocks:22219): GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `GtkRadioMenuItem'

(codeblocks:22219): Gtk-CRITICAL **: IA__gtk_radio_menu_item_get_group: assertion `GTK_IS_RADIO_MENU_ITEM (radio_menu_item)' failed

after (or while) loading the project the following errors are shown:

Code

(codeblocks:22219): GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `GtkRadioMenuItem'

(codeblocks:22219): Gtk-CRITICAL **: IA__gtk_radio_menu_item_get_group: assertion `GTK_IS_RADIO_MENU_ITEM (radio_menu_item)' failed

** (codeblocks:22219): CRITICAL **: murrine_style_draw_flat_box: assertion `width >= -1' failed

** (codeblocks:22219): CRITICAL **: murrine_style_draw_flat_box: assertion `width >= -1' failed

The radio-errors/warnings are there for a long time (debugger-menu), the last two assertions are caused by wxExecute as far as I know and are also old.

The first two (execvp) messages are new as far as I can tell.
I will try to dig into it deeper (maybe Null-compiler ?).

[oBFusCATed]

But in normal mode it hangs reliably if it tries to build the first target.

So, if I understand correctly you are unable to build cb in the described case?

The first two (execvp) messages are new as far as I can tell.
I will try to dig into it deeper (maybe Null-compiler ?).

Yes, they are caused by the xml compiler code, Alpha can you look at them?

[Jenna]

But in normal mode it hangs reliably if it tries to build the first target.

So, if I understand correctly you are unable to build cb in the described case?

The first two (execvp) messages are new as far as I can tell.
I will try to dig into it deeper (maybe Null-compiler ?).

Yes, they are caused by the xml compiler code, Alpha can you look at them?

The error is triggered by bool Compiler::EvalXMLCondition(const wxXmlNode* node) .

This fixes the error, that causes "-version" to be the only command.
The error-message itself will still be there.
I suggest catching the error output and either give a more clear error message or just suppress it.

Code

Index: src/plugins/compilergcc/resources/compilers/options_clang.xml
===================================================================
--- src/plugins/compilergcc/resources/compilers/options_clang.xml
+++ src/plugins/compilergcc/resources/compilers/options_clang.xml
@@ -25,7 +25,9 @@
         <Program name="LD"        value="clang++"/>
         <Program name="DBGconfig" value="gdb_debugger:Default"/>
         <Program name="LIB"       value="llvm-ar"/>
-        <if exec="llvm-ar -version">
+        <!-- LIB will be expanded to llvm-ar by Compiler::GetExecName()
+             llvm-ar can not be directly used here, because it can not be evaluated -->
+        <if exec="LIB -version">
             <!-- found, do nothing -->
         </if>
         <else>

And yes I can not compile C::B from a C::B running inside C::B which has no console output (either real console or gdb).