Compiler and project file changes in latest SVN.

[mandrav]

Compiler is now *not* using makefilegenerator.cpp for commands generation, as it was the culprit for the discovered slow times before actual compilation started.
A separate class has been created to generate build commands, which is *much* faster.
I 've tested it for 4 days now and seems to work fine. it even builds C::B, so I guess it really is working .
But if you encounter any unusual issues while building your projects, take a look at the actual command line to verify it is correct.

--------------

"GNU make" build method is now obsolete. You can't select it. It is automatically used *only* for projects that are using custom makefiles.
The actual commands to build a project/target/file using a custom makefile are now user-customizable and can be set per-project or per-target. The relevant options have been added in the project build options dialog.

--------------

The project file version has been pumped to 1.2 because some default values have changed. By "default values" I mean the values of elements that are missing from the project file.
Specifically:

• PCH mode now defaults for PCH to be created in the object output directory.
• "Build this target with ALL" now defaults to "no" (so "targets" now resemble MSVC "configurations").

Hooks to upgrade older project file versions are in-place so you shouldn't notice any problems...
Also, project saving has undergone some optimizations to only save almost only what's different from the default values.

[killerbot]

Great, any changes (next to those other project changes)  with respect to "http://forums.codeblocks.org/index.php/topic,1478.0.html" (otherwise I still need to file it). 

[Urxae]

PCH mode now defaults for PCH to be created in the object output directory.

I saw this change in the Subversion logs and was just about to start a topic asking why this change was made. Guess I'll ask here.
My problem: doesn't this break code like

Code

#include "precompiled_header.h"

when said file is indeed in the same directory?
And when I say "break", I mean: does it still use the precompiled header? Wouldn't it find the actual header first?

[lesnewell]

I saw this change in the Subversion logs and was just about to start a topic asking why this change was made. Guess I'll ask here.
My problem: doesn't this break code like

Code

#include "precompiled_header.h"

when said file is indeed in the same directory?
And when I say "break", I mean: does it still use the precompiled header? Wouldn't it find the actual header first?

It shouldn't. The compiler looks for the pch first. If it can't find it or if the pch is incorrect then it uses the header file.

[Urxae]

I saw this change in the Subversion logs and was just about to start a topic asking why this change was made. Guess I'll ask here.
My problem: doesn't this break code like

Code

#include "precompiled_header.h"

when said file is indeed in the same directory?
And when I say "break", I mean: does it still use the precompiled header? Wouldn't it find the actual header first?

It shouldn't. The compiler looks for the pch first. If it can't find it or if the pch is incorrect then it uses the header file.

Yes it does: it first looks in the current directory for the pch, doesn't find it (since it's in the object dir), then looks for the header and finds it.
Basically, it uses this algorithm:

Code

for each directory in search path ('.' is first if the file is #included "like_this")
    if (pch present) return pch
    if (header present) return header

Since the current directory is put in front of all other paths when using "" to #include a file, it looks there first even if the object dir (with the pch in it) is the first entry in the include paths given on the command line.
Unless I'm missing something and there's a command-line option to put a path in the "" lookup phase. (And C::B uses this when pchs are put in the object dir)

[rickg22]

Yiannis: YAY!

I'll update my SVN today and compare the generation times!

P.S. Did you read my post on the macrosmanager optimization?

[mandrav]

Great, any changes (next to those other project changes)  with respect to "http://forums.codeblocks.org/index.php/topic,1478.0.html" (otherwise I still need to file it). 

Not yet, but will be fixed too.

PCH mode now defaults for PCH to be created in the object output directory.

I saw this change in the Subversion logs and was just about to start a topic asking why this change was made. Guess I'll ask here.
My problem: doesn't this break code like

Code

#include "precompiled_header.h"

when said file is indeed in the same directory?
And when I say "break", I mean: does it still use the precompiled header? Wouldn't it find the actual header first?

It works now. Update your sources

[mandrav]

P.S. Did you read my post on the macrosmanager optimization?

Yes, but I wait for *your* speed measurements

[Urxae]

PCH mode now defaults for PCH to be created in the object output directory.

I saw this change in the Subversion logs and was just about to start a topic asking why this change was made. Guess I'll ask here.
My problem: doesn't this break code like

Code

#include "precompiled_header.h"

when said file is indeed in the same directory?
And when I say "break", I mean: does it still use the precompiled header? Wouldn't it find the actual header first?

It works now. Update your sources

I did. But I'd just finished a long recompile and didn't feel like doing one again, especially if I wasn't sure it'd work.
How did you fix it, by the way? Is there an option to add a library to the "" search path? I wouldn't be surprised if there was, I'd just like to know what it is as I searched for it and couldn't find it a while back.
I'd look at the commit in detail, but it's a mixed one with lots of changes...

EDIT: Oh, you meant update them again, as in you just fixed it?

By the way, is it really a good idea to put all C::B SDK headers into a precompiled header and have pretty much everything depend on it? One change to macrosmanager.h and it's an almost full rebuild .
I myself usually use pchs only for stuff that actually doesn't change for large amounts of time only: windows.h and headers for libraries like wxWidgets and Boost.
They're meant to cut down compilation time, but if you put your own (changing) stuff in there they may actually increase it by increasing dependencies.

[rickg22]

By the way, is it really a good idea to put all C::B SDK headers into a precompiled header and have pretty much everything depend on it? One change to macrosmanager.h and it's an almost full rebuild .

PCH or not, a change in the SDK headers will require a full rebuild. My full rebuild takes about 7 mins with PCH, 11 minutes without. Anyway, don't think we'll be doing SDK changes so often... this was because of an extraordinary bug and optimization. And the *managers are a fundamental part of the SDK. Don't expect changes like these very often.

[Urxae]

By the way, is it really a good idea to put all C::B SDK headers into a precompiled header and have pretty much everything depend on it? One change to macrosmanager.h and it's an almost full rebuild .

Doh what do you think the precompiled headers were for? PCH or not, a change in the SDK headers will require a full rebuild. My full rebuild takes about 7 mins with PCH, 11 minutes without.

No, a change in the SDK headers doesn't necessarily mean a full rebuild without PCHs. If a header isn't included directly or indirectly into a .cpp file, that .cpp doesn't need to be recompiled if (only) that header changes. A relink should take care of the problem.
By the way, my full rebuild takes over an hour typically. Not everyone has a new computer, and in fact I use a fairly old laptop.
Because of the time requirements I usually run C::B compiles that involve the precompiled headers in the background at a lower priority, which of course only adds to the required time...
If anyone knows a non-cygwin Windows version of distcc that would be very helpful, as there's also a less old non-laptop computer in the house...

[rickg22]

OUCH... sorry to hear that.

Edit: Look what I found!

http://lists.samba.org/archive/distcc/2005q4/003192.html

A patch for distcc to make it mingw friendly! Now you only have to recompile distcc... :?

[mandrav]

I did. But I'd just finished a long recompile and didn't feel like doing one again, especially if I wasn't sure it'd work.
How did you fix it, by the way? Is there an option to add a library to the "" search path? I wouldn't be surprised if there was, I'd just like to know what it is as I searched for it and couldn't find it a while back.
I'd look at the commit in detail, but it's a mixed one with lots of changes...

Look at the gcc options, specifically [-I-]. Here.
For gcc-4.0+ this has been deprecated and [-iquote] should be used. Here.

By the way, is it really a good idea to put all C::B SDK headers into a precompiled header and have pretty much everything depend on it? One change to macrosmanager.h and it's an almost full rebuild .
I myself usually use pchs only for stuff that actually doesn't change for large amounts of time only: windows.h and headers for libraries like wxWidgets and Boost.
They're meant to cut down compilation time, but if you put your own (changing) stuff in there they may actually increase it by increasing dependencies.

Yes, that's what PCHs are for. But if you 're using the SVN version, you must be prepared for a few rebuilds now and then. Even without PCHs, a change in configmanager.h would still require a full rebuild...

[Urxae]

Look what I found!

http://lists.samba.org/archive/distcc/2005q4/003192.html

A patch for distcc to make it mingw friendly! Now you only have to recompile distcc... :?

Unfortunately, the fact that the changes are in #ifdef __CYGWIN32__ doesn't bode well . Apparently when they say mingw on the distcc site they mean the one from cygwin.
 
I tried anyway:
./configure (ran from msys) doesn't work:

Code

checking for socklen_t... no
checking for socklen_t equivalent... configure: error: Cannot find a type to use in place of socklen_t

I had to some CFLAGS and create a dummy sys/sockets.h that just #includes <ws2tcpip> (winsock 2 header which typedefs socklen_t), but then the configure script ran.
Unfortunately make definitely didn't, it gave about 691 lines of error messages on the first file it tried to compile :shock:.
Haven't been able to fix this . Looks like no distcc for Windows users that don't want to install cygwin...

[rickg22]

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

[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