On Wed, Jul 16, 2008 at 5:06 PM, Tim Baumgartner <[EMAIL PROTECTED]> wrote: > Ari Johnson wrote: >> On Wed, Jul 16, 2008 at 4:44 PM, Tim Baumgartner <[EMAIL PROTECTED]> wrote: >>> Ari Johnson wrote: >>>> On Wed, Jul 16, 2008 at 3:33 PM, Tim Baumgartner <[EMAIL PROTECTED]> wrote: >>>>> There is a Leopard compile problem (http://gna.org/bugs/?11940) in which >>>>> QuesoGLC fails to link due to the location of some inline function >>>>> definitions. I came up with a patch that fixes the issue (and submitted it >>>>> to the QuesoGLC tracker) but I don't know when the problem will be fixed >>>>> on >>>>> the official QuesoGLC version. >>>>> >>>>> So that the problem doesn't persist for Leopard users trying to compile >>>>> the >>>>> Warzone trunk and/or 2.1 branch, I've modified the Xcode file so that it >>>>> automatically applies the QuesoGLC patch during compilation. If this >>>>> solution works for everyone (until QuesoGLC itself is fixed), I've >>>>> attached >>>>> both the QuesoGLC and Xcode patches. The script assumes the QuesoGLC patch >>>>> is located in macosx/Resources/ because I didn't know a better place to >>>>> put >>>>> it but the location can easily be changed. >>>> >>>> My standard procedure would be to commit the patch into >>>> /macosx/external/. Also, the patch should probably be applied in the >>>> script that extracts the QuesoGLC code into that directory, and only >>>> if the extraction takes place. That would avoid multiple applications >>>> of the patch, although it would require a rm -rf >>>> macosx/external/quesoglc in existing checkouts. >>>> >>>> Oh, how I'd love for a better way to do it. But that's the best I >>>> came up with and it works pretty well, on the whole. :) >>>> >>>> Ari >>>> >>> The script runs right after the script that downloads and extracts >>> QuesoGLC. I >>> put it in a new "script build phase" so that it would be easier to remove >>> once >>> QuesoGLC fixes the issue on their end but I can put it in the download >>> script if >>> you want. >>> >>> For the actual patching, the script copies the patch from macosx/Resources/ >>> to >>> macosx/external/quesoglc/ and patches it from there. If the patch is in the >>> quesoglc directory, the script assumes QuesoGLC has already been patched and >>> doesn't try to re-patch it. This would alleviate the problem of having to >>> rm -rf >>> the quesoglc directory in existing checkouts. >>> >>> In regards to storing the patch (the one I currently have in >>> macosx/Resources/), >>> you would like for it to be stored in macosx/external/, correct? >> >> What you're doing is fine, but I do think that the patch should not be >> in macosx/Resources/. The reason for this is that the Resources >> directory is intended for files that will be placed inside the >> application bundle or framework bundles that are created in the build >> process. That is, resources for the application rather than resources >> for the build. >> > > That makes sense, I just wanted to clear up a little confusion that I had. > Also, > do you still prefer for the patching to be applied in the download script? > I'll > make the changes and post back later today.
No. I like it being separate, as long as it is intelligent about deciding whether to actually apply the patch. :) _______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
