[Tinman]

SVN 5694 commit breaks MacOSX compiling - please look into it  

[portej05]

Fixed in 5698.

Next time, please include some more information than 'it's borked'!

Issue was that disableWindowsKey was moved from within WinMain (protected by _WIN32 ifdef) into game_main (not protected by _WIN32 ifdef)

[Tinman]

Next time, please include some more information than 'it's borked'!

I'll do.
But as the 5694 commit was only the Windowskey-thing I thought that was clear  

Thanks for the fast response!

[chief1983]

Yeah I'll admit, that was even my hunch just after looking at the diff

[Tinman]

Not the best thread to mention it: but the MacOS X building process is broken again. 
As far as I can see it is SVN5715 (with a lot of errors)
One of the MacOS X developers may have to look into this 

[Zacam]

Nope. Update to 5716. Portej forgot to sync the new gropenglpostprocessing.cpp anh .h files when he merged Antipodes into Trunk.

[Tinman]

Yes. I used SVN5716 to build fs2Open (and added the files of 5716 manually to the XCode project) but it throws 24+ errors
(I tested SVN5713: build process ok)

[Zacam]

Hmm. Hery's original commit of postprocessing to Antipodes included xcode updates, as did portej's port of it to Trunk. See the patch in my latest Test Build for confirmation.

What are the errors that it throws? And can you revert or checkout a 5713 and apply the postprocessing.patch from my Test Build post and see if it does the same behaviour?

[portej05]

Zacam: I probably screwed something up - I've got no way of testing Xcode files
(sorry about forgetting gropenglpostprocessing.cpp/h - fixed now though!)

[Zacam]

****. It seems my .patch nor Hery's original .patch included xcode data. Frak.

[Echelon9]

I also noticed that commit 5715/5716 (Antipodes #4) didn't update the Xcode project file. I've updated my local Xcode project file and am running a test build now.

Results should be available soon - and I can commit my locally change Xcode project file if all is green.

Update: Xcode project file has been updated so that the gropenglpostprocessing.cpp/h files are included. I committed a small fix to address GCC's capitalisation requirements for MIN(). Compile issues still remain at present, further work needed.

[Zacam]

Sweet. Thank you, Echelon9. I'm pretty sure my notepad hack job in 5718 wasn't going to do it.

FYI, there was a line added to xcode in the merge (4949) that according to chief was removed for a reason. Keep that in mind if you need to and feel free to pluck it back out if you have to.

[Tinman]

I don't know if it is of any help, but this are some error-messages (after SVN5719)

[attachment deleted by admin]

[Hery]

That was obviously my fault. Looks like I confused object types while merging old shaders management code with the shaders manager.
I'm already solving that problem.

[Echelon9]

Hery, I applied the patch you provided to Tinman and myself. Improved, but there are three remaining compile errors on my platform.

Code: [Select]

../../code/graphics/gropenglshader.cpp:438: error: prototype for 'void opengl::shader::set_uniform(unsigned int, GLint)' does not match any in class 'opengl::shader'
../../code/graphics/gropenglshader.h:163: error: candidates are: void opengl::shader::set_uniform(unsigned int, float)
../../code/graphics/gropenglshader.h:157: error:                 void opengl::shader::set_uniform(unsigned int, int)

Was Tinman able to compile a clean build?

[Tinman]

Yes. Compiled without errors. MacOS X 10.6.2 , XCode 3.2.1.

[Echelon9]

Thanks Tinman. My remaining compile issues with Hery's shader code may be platform specific; I'm using Xcode 2.5 on MacOS X 10.4.11 (PPC) while my primary development laptop is in for repairs.

[Hery]

This patch solves this problem. Let me know if there is still something else to fix.

[attachment deleted by admin]

[Tinman]

Compiling works fine on my Mac with latest patch.
Application is also working! 

[Echelon9]

Gah... I am having a frustrating time trying to apply this patch file (last time I had to make the changes manually).

Code: [Select]

$ patch -p0 -i ../gcc_macosx_fix.patch
(Stripping trailing CRs from patch.)
patching file code/graphics/gropenglshader.cpp
Hunk #1 FAILED at 250.
Hunk #2 FAILED at 313.
Hunk #3 FAILED at 381.
Hunk #4 FAILED at 425.
Hunk #5 FAILED at 475.
5 out of 5 hunks FAILED -- saving rejects to file code/graphics/gropenglshader.cpp.rej
(Stripping trailing CRs from patch.)
patching file code/graphics/gropenglshader.h
Hunk #1 FAILED at 154.
Hunk #2 FAILED at 204.
Hunk #3 FAILED at 214.
Hunk #4 FAILED at 233.
Hunk #5 FAILED at 325.
Hunk #6 FAILED at 334.
Hunk #7 FAILED at 344.
Hunk #8 FAILED at 353.
Hunk #9 FAILED at 383.
9 out of 9 hunks FAILED -- saving rejects to file code/graphics/gropenglshader.h.rej
It's not happening because I am trying to apply this to a working copy at a different revision to the patch, as both are 5726.

Code: [Select]

$ svn info
Path: .
URL: svn://svn.icculus.org/fs2open/trunk/fs2_open
Repository Root: svn://svn.icculus.org/fs2open
Repository UUID: 387891d4-d844-0410-90c0-e4c51a9137d3
Revision: 5726
Node Kind: directory
Schedule: normal
Last Changed Author: Sushi
Last Changed Rev: 5726
Last Changed Date: 2009-12-19 01:22:01 +0800 (Sat, 19 Dec 2009)
Properties Last Updated: 2009-12-14 17:03:41 +0800 (Mon, 14 Dec 2009)

$ head -n 4 ../gcc_macosx_fix.patch
Index: code/graphics/gropenglshader.cpp
===================================================================
--- code/graphics/gropenglshader.cpp    (revision 5726)
+++ code/graphics/gropenglshader.cpp    (working copy)
I've Google'd for newline and CRLF issues when using a Windows produced patch on OS X / Unix with no success with any of the suggested fixes, nor with --ignore-whitespaces or -Fn. Any help or suggestions?