Compiler and project file changes in latest SVN.

[Urxae]

Why not post a bug report on the distcc site? Annoy those guys until they get it working ;-)

It's not so much a bug as a completely unsupported platform . Only Windows with cygwin is supported...

[yop]

Here's what I got building a cb plugin using latest svn build.

Code

mingw32-g++.exe -Wall -D__GNUWIN32__ -DWXUSINGDLL -DBUILDING_PLUGIN  -IC:\wxWidgets-2.6.2\include -IC:\wxWidgets-2.6.2\lib\gcc_dll\msw -IC:\wxWidgets-2.6.2\contrib\include -IC:\Documents and Settings\yop\My Documents\Workbench\codeblocks\src\sdk -IC:\Documents and Settings\yop\My Documents\Workbench\codeblocks\src\sdk\tinyxml -IC:\Documents and Settings\yop\My Documents\Workbench\codeblocks\src\sdk\wxscintilla\include -IC:\MinGW\include  -c qtworkbench.cpp -o .objs\qtworkbench.o
qtworkbench.cpp:14:26: pipedprocess.h: No such file or directory
qtworkbench.cpp:15:21: manager.h: No such file or directory
qtworkbench.cpp:16:69: licenses.h: No such file or directory
qtworkbench.cpp:17:28: projectmanager.h: No such file or directory
In file included from qtworkbench.cpp:18:
qtworkbench.h:26:58: cbplugin.h: No such file or directory
qtworkbench.h:27:60: settings.h: No such file or directory

It used to compile yesterday 
The files it complains about are in C:\Documents and Settings\yop\My Documents\Workbench\codeblocks\src\sdk which is in -I

[Urxae]

Code

mingw32-g++.exe [...] -IC:\Documents and Settings\yop\My Documents\Workbench\codeblocks\src\sdk -IC:\Documents and Settings\yop\My Documents\Workbench\codeblocks\src\sdk\tinyxml -IC:\Documents and Settings\yop\My Documents\Workbench\codeblocks\src\sdk\wxscintilla\include [...]

Looks like there's a bug in the new command line generator: it doesn't properly quote parameters with spaces in them.
You might want to file a bug report here (unless of course one of the developers replies it's fixed already before you see this )

[rickg22]

I tested the modified compilation, and I'm very satisfied with it!

The delay has shortened to 0.8 seconds, and I doubt it can get any better!

Now it's only matter of fixing those paths.

[mandrav]

Code

mingw32-g++.exe [...] -IC:\Documents and Settings\yop\My Documents\Workbench\codeblocks\src\sdk -IC:\Documents and Settings\yop\My Documents\Workbench\codeblocks\src\sdk\tinyxml -IC:\Documents and Settings\yop\My Documents\Workbench\codeblocks\src\sdk\wxscintilla\include [...]

Looks like there's a bug in the new command line generator: it doesn't properly quote parameters with spaces in them.
You might want to file a bug report here (unless of course one of the developers replies it's fixed already before you see this )

Thanks for this. I 'll fix it ASAP.

[mandrav]

A quick test showed that the code actually does quote paths with spaces.
This leads me to believe that you have setup a global (or user) variable for C::B SDK, i.e.

Code

CB_SDK=C:\Documents and Settings\yop\My Documents\Workbench\codeblocks\src

So this is actually expanded without quotes...
Is this the case?

One part of the optimizations, has to do with macro expansion being performed just once, after the command-line has been generated. This would explain the change of behaviour.
Have you tried quotting the variable's value?

[yop]

A quick test showed that the code actually does quote paths with spaces.

I also checked the source before posting and I also saw that (it would be an easy one otherwise

This leads me to believe that you have setup a global (or user) variable for C::B SDK, i.e.

Code

CB_SDK=C:\Documents and Settings\yop\My Documents\Workbench\codeblocks\src

So this is actually expanded without quotes...
Is this the case?

One part of the optimizations, has to do with macro expansion being performed just once, after the command-line has been generated. This would explain the change of behaviour.
Have you tried quotting the variable's value?

Yes this seems to be the case, I do have a global variable (what an amazing feature btw), I'll try quoting this afternoon when I return from work. If that's the case though, the gobal variable has been set using the "..." button in the global variables dialog that allows you to browse to the location you want to set the global variable to, then it won't get quoted and leed to the above errors. So some of the usability of the global vars is lost (although you just have to do the quoting thingy once ). It's not a big deal after all, it's just a decision you have to make on the design/usability/features of the global variables.

[mandrav]

If that's the case though, the gobal variable has been set using the "..." button in the global variables dialog that allows...<snipped>

Yes, the subject of this topic is the change in command-line generation so we can find and fix these problems