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 #include "precompiled_header.h"
And when I say "break", I mean: does it still use the precompiled header? Wouldn't it find the actual header first?
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 #include "precompiled_header.h"
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:
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
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)
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: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...
Here's what I got building a cb plugin using latest svn build.
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
The files it complains about are in C:\Documents and Settings\yop\My Documents\Workbench\codeblocks\src\sdk which is in -I
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.
CB_SDK=C:\Documents and Settings\yop\My Documents\Workbench\codeblocks\src
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?