5 - Apple Developer Tools
8 There are two ways to build SOPE on MacOSX, either using the gnustep-make
9 package or as native Xcode projects. The first option is usually used when
10 you build SOPE for use with OGo, while the latter is more appropriate for
13 Building using gstep-make:
14 ==========================
16 First install gnustep-make (eg v1.8), then ensure that GNUstep.sh is properly
17 sources. For the build just enter:
20 make -s debug=yes install
21 if you build with debug informations.
26 The Xcode build comes in two variants, one for development and the other for
32 Development usually means you're happily hacking away at your pet
33 projects and sometimes want to update the SOPE frameworks. For this purpose
34 use the "all" target and the accompanied "Development" build style. Later,
35 you can narrow the target down to something more specific. For development we
36 assume the destination for frameworks to be /Library/Frameworks. Once you are
37 done building all the frameworks the loader commands of the frameworks will
38 have that destination path built in. In order to use the frameworks you either
39 have to install them (by copying them manually to their destination) or to
40 prepare symlinks from /Library/Frameworks to the place where the built products
41 are. I usually build everything in a central place (i.e. /Local/BuildArea) and
42 have symlinks from /Library/Frameworks to /Local/BuildArea for each of the
45 Also the following products are expected to be in the following locations:
46 *.sax -> /Library/SaxDrivers
47 *.sxp -> /Library/SoProducts
49 Either copy them to the appropriate places or symlink them (my suggestion).
54 Deployment in our terms means you want to copy all required SOPE products into
55 an application's app wrapper. For this step all frameworks need to be built in
56 a special fashion, as the "install_name" of the frameworks needs to be prepared
57 to point to a relative path in the app wrapper. The situation is even more
58 complicated as all frameworks during linking store the "install names" of other
59 frameworks in their mach loader commands. In order for this step not to break
60 we need to set up an environment which is clearly separated from the
61 Development environment. I chose to use $(USER_LIBRARY_DIR)/EmbeddedFrameworks
62 as the default destination for these builds. In order for your application to
63 easily pick up the built products and copy them into its app wrapper this
64 location needs to be fixed and easily accessible. Note that on my system
65 ~/Library/EmbeddedFrameworks is a symlink to /Library/EmbeddedFrameworks so
66 even if you don't like the location at all it's very easy to point it to
67 somewhere else. As soon as you have set this up you can use the
68 "Wrapper Contents" target with the accompanied "Wrapper" build style to build
69 all wrapper contents in the appropriate fashion. When you're done you can copy
70 all the wrapper products into your application's wrapper. The expected
71 destination is the "Frameworks" directory in the wrappers "Contents" directory.
72 For a complete list of what you need to copy into your application's wrapper
73 see the "Direct Dependencies" of all "Wrapper Contents" targets in all SOPE
74 related projects. At the time of this writing the complete list for SOPE
75 consisted of the following:
84 NGExtensions.framework
99 Note: "A word on umbrellas"
100 The general idea of umbrellas is to make life easier by providing a cover
101 for linking. In an ideal world we would provide a SOPE umbrella (we
102 actually do that) and you just link against that and forget about the
103 complete list. However, with the "Wrapper" style things do not work that
104 way. Because the "install name"s of all frameworks are relative paths,
105 during linking the mach dyld cannot find the dependend frameworks
106 (because the path isn't absolute) and thus symbol checking fails. This
107 directly leads to prebinding to fail which we really don't want since we
108 have such a huge dependency tree and prebinding escpecially in our case
109 speeds up loading significantly. So, umbrellas do not really help with
110 "Wrapper" products - in fact they just add to the overall dependency
111 graph without providing any benefit. With the notable exception of the
112 "Development" build style umbrellas are totally useless. If you're
113 not planning to do a "Wrapper" deployment you might be happy to have
114 the umbrellas, however, that's why they are still here.
116 Note: You cannot use the -buildAllTargets commandline argument for Xcode,
117 because the Xcode projects also contain a target to build in the
118 gstep-make environment (called GSM:all)
124 General technical information about prebinding is available from Apple at
125 http://developer.apple.com/documentation/Performance/Conceptual/LaunchTime/Tasks/Prebinding.html#//apple_ref/doc/uid/20001858.
127 OGo frameworks currently use the range from 0xC0000000 to 0xCFFFFFFF.
129 Any questions and feedback regarding our use of this range should go to
130 Marcus Müller <znek@mulle-kybernetik.com>.
133 sope-core: 0xC1000000 - 0xC2FFFFFF
134 ==================================
137 0xC1200000 NGExtensions
139 0xC2E00000 EOCoreData