Re: [Warzone-dev] Patch for Leopard QuesoGLC Linking Problem
Tim Baumgartner wrote: > Ari Johnson wrote: >> On Tue, Jul 22, 2008 at 2:28 PM, Giel van Schijndel <[EMAIL PROTECTED]> >> wrote: >>> Tim Baumgartner schreef: Ari Johnson wrote: > No. I like it being separate, as long as it is intelligent about > deciding whether to actually apply the patch. :) Alright, the Xcode script now looks for the QuesoGLC patch in macosx/external/. The updated Xcode project file patch is attached. >>> Question: did this patch or any variant of it got applied to trunk or 2.1? >>> >>> I'd be happy to apply a patch if necessary, but I haven't got any Macs >>> in my reach to test with, and I'd rather not break the Xcode build >>> system we've got right now. >> The Xcode build system is, to my knowledge, still broken for trunk >> because of requirements of a version of Bison that OS X doesn't come >> with and which nobody has bothered to add to the Xcode system yet. I >> could be wrong, though. > > The patch hasn't been applied to the trunk or 2.1 branch. > > I'll look into adding Bison to the Xcode project but I probably won't be able > to > do anything until the end of the week or next week. > Is anyone able to test this patch and/or apply it? It would bring us one step closer to making the dream of a painless OS X build into a reality ;) Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch for Leopard QuesoGLC Linking Problem
Ari Johnson wrote: > On Tue, Jul 22, 2008 at 2:28 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote: >> Tim Baumgartner schreef: >>> Ari Johnson wrote: No. I like it being separate, as long as it is intelligent about deciding whether to actually apply the patch. :) >>> Alright, the Xcode script now looks for the QuesoGLC patch in >>> macosx/external/. The updated Xcode project file patch is attached. >> Question: did this patch or any variant of it got applied to trunk or 2.1? >> >> I'd be happy to apply a patch if necessary, but I haven't got any Macs >> in my reach to test with, and I'd rather not break the Xcode build >> system we've got right now. > > The Xcode build system is, to my knowledge, still broken for trunk > because of requirements of a version of Bison that OS X doesn't come > with and which nobody has bothered to add to the Xcode system yet. I > could be wrong, though. The patch hasn't been applied to the trunk or 2.1 branch. I'll look into adding Bison to the Xcode project but I probably won't be able to do anything until the end of the week or next week. Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch for Leopard QuesoGLC Linking Problem
On Tue, Jul 22, 2008 at 2:28 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote: > Tim Baumgartner schreef: >> Ari Johnson wrote: >>> No. I like it being separate, as long as it is intelligent about >>> deciding whether to actually apply the patch. :) >> >> Alright, the Xcode script now looks for the QuesoGLC patch in >> macosx/external/. The updated Xcode project file patch is attached. > > Question: did this patch or any variant of it got applied to trunk or 2.1? > > I'd be happy to apply a patch if necessary, but I haven't got any Macs > in my reach to test with, and I'd rather not break the Xcode build > system we've got right now. The Xcode build system is, to my knowledge, still broken for trunk because of requirements of a version of Bison that OS X doesn't come with and which nobody has bothered to add to the Xcode system yet. I could be wrong, though. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch for Leopard QuesoGLC Linking Problem
Tim Baumgartner schreef: > Ari Johnson wrote: >> No. I like it being separate, as long as it is intelligent about >> deciding whether to actually apply the patch. :) > > Alright, the Xcode script now looks for the QuesoGLC patch in > macosx/external/. The updated Xcode project file patch is attached. Question: did this patch or any variant of it got applied to trunk or 2.1? I'd be happy to apply a patch if necessary, but I haven't got any Macs in my reach to test with, and I'd rather not break the Xcode build system we've got right now. -- Giel signature.asc Description: OpenPGP digital signature ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch for Leopard QuesoGLC Linking Problem
Ari Johnson wrote: 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. :) Alright, the Xcode script now looks for the QuesoGLC patch in macosx/external/. The updated Xcode project file patch is attached. Tim Index: macosx/Warzone.xcodeproj/project.pbxproj === --- macosx/Warzone.xcodeproj/project.pbxproj(revision 5562) +++ macosx/Warzone.xcodeproj/project.pbxproj(working copy) @@ -3171,6 +3171,7 @@ buildConfigurationList = 0223BBD30CFE3D5C0056EF85 /* Build configuration list for PBXNativeTarget "QuesoGLC" */; buildPhases = ( 0223BBDD0CFE3E290056EF85 /* Fetch source */, + 22E849A80E2E0E8F002591A4 /* Patch */, 02F5CC4F0D148FC3A2D0 /* Create database.c */, 0223BBCC0CFE3D5C0056EF85 /* Headers */, 0223BBCD0CFE3D5C0056EF85 /* Resources */, @@ -3741,6 +3742,20 @@ shellPath = /bin/sh; shellScript = "DIRECTORY=\"SDL_net-1.2.6\"\nOUTDIR=\"SDL_net\"\nFILENAME=\"SDL_net-1.2.6.tar.gz\"\nSOURCE=\"http://www.libsdl.org/projects/SDL_net/release/SDL_net-1.2.6.tar.gz\"\nMD5=\"7be5b9ef36129ee187ace96906cd264c\"\n\ncd external\n\nif [ -d \"$OUTDIR\" ]; then\n echo \"$OUTDIR already exists, skipping\"\n exit 0\nfi\n\nif [ -d \"$DIRECTORY\" ]; then\n echo \"$DIRECTORY exists, probably from an earlier failed run\" >&2\n exit 1\nfi\n\nif [ ! -r \"$FILENAME\" ]; then\n echo \"Fetching $SOURCE\"\n if ! curl -L -o \"$FILENAME\" \"$SOURCE\"; then\necho \"Unable to fetch $SOURCE\" >&2\n exit 1\n fi\nfi\n\nHAVEMD5=`md5 \"$FILENAME\" | sed -n -e 's/^MD5 (\\(.*\\)) = \\(.*\\)$/\\2/p'`\n\nif [ -z \"$HAVEMD5\" ]; then\n echo \"Unable to compute md5 for $FILENAME\" >&2\n exit 1\nfi\n\nif [ \"$HAVEMD5\" != \"$MD5\" ]; then\n echo \"Md5 does not match for $FILENAME\" >&2\n exit 1\nf
Re: [Warzone-dev] Patch for Leopard QuesoGLC Linking Problem
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
Re: [Warzone-dev] Patch for Leopard QuesoGLC Linking Problem
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. Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch for Leopard QuesoGLC Linking Problem
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. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch for Leopard QuesoGLC Linking Problem
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? Tim ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Patch for Leopard QuesoGLC Linking Problem
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
>
> Tim
>
>
> Index: macosx/Warzone.xcodeproj/project.pbxproj
> ===
> --- macosx/Warzone.xcodeproj/project.pbxproj(revision 5562)
> +++ macosx/Warzone.xcodeproj/project.pbxproj(working copy)
> @@ -3171,6 +3171,7 @@
>buildConfigurationList = 0223BBD30CFE3D5C0056EF85 /*
> Build configuration list for PBXNativeTarget "QuesoGLC" */;
>buildPhases = (
>0223BBDD0CFE3E290056EF85 /* Fetch source */,
> + 22E849A80E2E0E8F002591A4 /* Patch */,
>02F5CC4F0D148FC3A2D0 /* Create database.c
> */,
>0223BBCC0CFE3D5C0056EF85 /* Headers */,
>0223BBCD0CFE3D5C0056EF85 /* Resources */,
> @@ -3741,6 +3742,20 @@
>shellPath = /bin/sh;
>shellScript =
> "DIRECTORY=\"SDL_net-1.2.6\"\nOUTDIR=\"SDL_net\"\nFILENAME=\"SDL_net-1.2.6.tar.gz\"\nSOURCE=\"http://www.libsdl.org/projects/SDL_net/release/SDL_net-1.2.6.tar.gz\"\nMD5=\"7be5b9ef36129ee187ace96906cd264c\"\n\ncd
> external\n\nif [ -d \"$OUTDIR\" ]; then\n echo \"$OUTDIR already exists,
> skipping\"\n exit 0\nfi\n\nif [ -d \"$DIRECTORY\" ]; then\n echo
> \"$DIRECTORY exists, probably from an earlier failed run\" >&2\n exit
> 1\nfi\n\nif [ ! -r \"$FILENAME\" ]; then\n echo \"Fetching $SOURCE\"\n if
> ! curl -L -o \"$FILENAME\" \"$SOURCE\"; then\necho \"Unable to fetch
> $SOURCE\" >&2\nexit 1\n fi\nfi\n\nHAVEMD5=`md5 \"$FILENAME\" | sed -n
> -e 's/^MD5 (\\(.*\\)) = \\(.*\\)$/\\2/p'`\n\nif [ -z \"$HAVEMD5\" ]; then\n
> echo \"Unable to compute md5 for $FILENAME\" >&2\n exit 1\nfi\n\nif [
> \"$HAVEMD5\" != \"$MD5\" ]; then\n echo \"Md5 does not match for
> $FILENAME\" >&2\n exit 1\nfi\n\nEXTENSION=`echo $FILENAME | sed -e
> 's/^.*\\.\\([^.]*\\)/\\1/'`\n\nif [ \"$EXTENSION\" = \"gz\" ]; then\n if !
> tar -zxf \"$FILENAME\"; then\necho \"Unpacking $FILENAME failed\" >&2\n
>exit 1\n fi\nelif [ \"$EXTENSION\" = \"bz2\" ]; then\n if ! tar -jxf
> \"$FILENAME\"; then\necho \"Unpacking $FILENAME failed\" >&2\nexit
> 1\n fi\nelse\n echo \"Unable to unpack $FILENAME\" >&2\n exit 1\nfi\n\nif
> [ ! -d \"$DIRECTORY\" ]; then\n echo \"Can't find $DIRECTORY to rename\"
>>&2\n exit 1\nfi\n\nmv \"$DIRECTORY\" \"$OUTDIR\"\n";
>};
> + 22E849A80E2E0E8F002591A4 /* Patch */ = {
> + isa = PBXShellScriptBuildPhase;
> + buildActionMask = 2147483647;
> + files = (
> + );
> + inputPaths = (
> + );
> + name = Patch;
> + outputPaths = (
> + );
> + runOnlyForDeploymentPostprocessing = 0;
> + shellPath = /bin/sh;
> + shellScript =
> "GLCDIR=\"external/quesoglc/\"\nPATCHDIR=\"Resources/\"\nPATCH0=\"quesoglc_inline_0.diff\"
> # Fixes inline function linking error on Leopard systems (bug #11940)\n\nif
> [ ! -d \"$GLCDIR\" ]; then\n echo \"$GLCDIR does not exist. QuesoGLC could
> not be patched.\" >&2\n exit 1\nfi\n\nif [ ! -e \"$PATCHDIR\"\"$PATCH0\" ];
> then\n echo \"$PATCHDIR$PATCH0 does not exist. QuesoGLC could not be
> patched.\" >&2\n exit 1\nfi\n\n## Patch 0 ##\n\n# Check if the patch
> already exists in the QuesoGLC directory.\n# If so, assume the patch has
> already been app
