summaryrefslogtreecommitdiffstats
path: root/doc/texi/building/chapter.via.xcode.texi
diff options
context:
space:
mode:
authorjstebbins <[email protected]>2010-06-04 16:27:15 +0000
committerjstebbins <[email protected]>2010-06-04 16:27:15 +0000
commit6141bbf563d067e4c2574f85871f1da4e1b664f2 (patch)
tree9b1a255082154ad1121895ecdb52a2cba60f7734 /doc/texi/building/chapter.via.xcode.texi
parent70ee5abfc5b28c7ed2f26ef0ec63a678d3681704 (diff)
MacGui: Add flexible dylib path manipulation so that we can handle external dylibs more easily
At startup, add any extra dylib paths to DYLD_FALLBACK_LIBRARY_PATH. This is the last path searched by the system for dylibs and we add our paths to the end of it's list, so this will never override any system libs or paths the user has explicitly set. Since applications read the environment once at startup, these changes don't take effect until we restart with execv. In order to avoid a possible exec bomb, we add a parameter to the argv list to prevent any further exec's. Note that this causes a minor glitch when running under gdb. The execv triggers a trap. You just have to 'continue'. git-svn-id: svn://svn.handbrake.fr/HandBrake/trunk@3351 b64f7644-9d1e-0410-96f1-a4d463321fa5
Diffstat (limited to 'doc/texi/building/chapter.via.xcode.texi')
-rw-r--r--doc/texi/building/chapter.via.xcode.texi2
1 files changed, 2 insertions, 0 deletions
diff --git a/doc/texi/building/chapter.via.xcode.texi b/doc/texi/building/chapter.via.xcode.texi
index 2b79a7bfc..0b0c2b435 100644
--- a/doc/texi/building/chapter.via.xcode.texi
+++ b/doc/texi/building/chapter.via.xcode.texi
@@ -23,6 +23,8 @@ Once the HandBrake Xcode project is open, perform the following steps to build t
@item click @b{Build} or @b{Build and Go}
@end itemize
+When using Build and Go, xcode launches the application under the gdb debugger. gdb will encounter a trap when starting the program. This trap is harmless and you should just 'continue'. For the curious, the trap occurs because we add some values to the environment with setenv, then do a brain transplant with execv. Restarting the application with execv triggers the trap.
+
The first build (on an empty @file{build} directory) will take a bit of time. You may use the Build Results window to observe progress. The most time-consuming part of the build is when the external build system (essentially the @b{terminal} method) is triggered by Xcode and a substantial amount of log transcript ensues. Much of that transcript are warnings and errors that are part of the normal build process for 3rd-party contributed modules so in general you need not do anything. However, if Xcode itself reports the build failed, then you must take corrective action.
Unfortunately, due to limitations of Xcode we do not have hooks in place to offer finer-grained control over per-module make actions for the (external) build system. Thus, you will have to use @b{terminal} to accomplish those tasks. Just @command{cd} into the build directory which is associated with your active configuration and perform any necessary @command{make} commands. @b{Be careful not to issue commands from the terminal simultaneously with Xcode tasks} as that will confuse both Xcode and make and likely corrupt your build directory.