err.no Git - sope/blob - sope-appserver/README-OSX.txt

   1 # $Id$
   2
   3 Building Notes
   4 ==============
   5
   6 Prerequisites:
   7 - Apple Developer Tools
   8 - skyrix-xml
   9 - skyrix-core
  10 - SpiderMonkey (as availably in OpenGroupware.org/ThirdParty/js-1.5/)
  11
  12 There are two ways to build SOPE on MacOSX, either using the gnustep-make
  13 package or as native Xcode projects. The first option is usually used when
  14 you build SOPE for use with OGo, while the latter is more appropriate for
  15 SOPE:X applications.
  16
  17 Building using gstep-make:
  18 ==========================
  19
  20 First install gnustep-make (eg v1.8), then ensure that GNUstep.sh is properly
  21 sources. For the build just enter:
  22   make -s install
  23 or
  24   make -s debug=yes install
  25 if you build with debug informations.
  26
  27 Building using Xcode:
  28 =====================
  29
  30 The Xcode build comes in two variants, one for development and the other for
  31 deployment.
  32
  33
  34 Development
  35 -----------
  36 Development usually means you're happily hacking away at your pet
  37 projects and sometimes want to update the SOPE frameworks. For this purpose
  38 use the "all" target and the accompanied "Development" build style. Later,
  39 you can narrow the target down to something more specific. For development we
  40 assume the destination for frameworks to be /Library/Frameworks. Once you are
  41 done building all the frameworks the loader commands of the frameworks will
  42 have that destination path built in. In order to use the frameworks you either
  43 have to install them (by copying them manually to their destination) or to
  44 prepare symlinks from /Library/Frameworks to the place where the built products
  45 are. I usually build everything in a central place (i.e. /Local/BuildArea) and
  46 have symlinks from /Library/Frameworks to /Local/BuildArea for each of the
  47 products.
  48
  49 Also the following products are expected to be in the following locations:
  50 *.sax -> /Library/SaxDrivers
  51 *.sxp -> /Library/SoProducts
  52
  53 Either copy them to the appropriate places or symlink them (my suggestion).
  54
  55
  56 Deployment
  57 ----------
  58 Deployment in our terms means you want to copy all required SOPE products into
  59 an application's app wrapper. For this step all frameworks need to be built in
  60 a special fashion, as the "install_name" of the frameworks needs to be prepared
  61 to point to a relative path in the app wrapper. The situation is even more
  62 complicated as all frameworks during linking store the "install names" of other
  63 frameworks in their mach loader commands. In order for this step not to break
  64 we need to set up an environment which is clearly separated from the
  65 Development environment. I chose to use $(USER_LIBRARY_DIR)/EmbeddedFrameworks
  66 as the default destination for these builds. In order for your application to
  67 easily pick up the built products and copy them into its app wrapper this
  68 location needs to be fixed and easily accessible. Note that on my system
  69 ~/Library/EmbeddedFrameworks is a symlink to /Library/EmbeddedFrameworks so
  70 even if you don't like the location at all it's very easy to point it to
  71 somewhere else. As soon as you have set this up you can use the
  72 "Wrapper Contents" target with the accompanied "Wrapper" build style to build
  73 all wrapper contents in the appropriate fashion. When you're done you can copy
  74 all the wrapper products into your application's wrapper. The expected
  75 destination is the "Frameworks" directory in the wrappers "Contents" directory.
  76 For a complete list of what you need to copy into your application's wrapper
  77 see the "Direct Dependencies" of all "Wrapper Contents" targets in all SOPE
  78 related projects. At the time of this writing the complete list for SOPE
  79 consisted of the following:
  80
  81 SxXML
  82   SaxObjC.framework
  83   DOM.framework
  84   XmlRpc.framework
  85
  86 SxCore
  87   EOControl.framework
  88   NGExtensions.framework
  89   NGStreams.framework
  90   NGMime.framework
  91   NGImap4.framework
  92   NGLdap.framework
  93   NGMail.framework
  94   NGiCal.framework
  95
  96 SOPE
  97   NGScripting.framework
  98   NGJavaScript.framework
  99   NGHttp.framework
 100   WebDAV.framework
 101   SoOFS.framework
 102   NGXmlRpc.framework
 103   WOExtensions.framework
 104   WEExtensions.framework
 105   NGObjDOM.framework
 106   NGObjWeb.framework
 107   js.framework (see NOTE)
 108
 109
 110 Note: js.framework is the Spidermonkey framework available in
 111       OpenGroupware.org/ThirdParty/js-1.5/. Although being located in
 112       ThirdParty this is technically considered to be a part of SOPE. This
 113       project also has an appropriate "Wrapper" build style which can be used
 114       for the "js" framework target.
 115
 116 Note: "A word on umbrellas"
 117       The general idea of umbrellas is to make life easier by providing a cover
 118       for linking. In an ideal world we would provide a SOPE umbrella (we
 119       actually do that) and you just link against that and forget about the
 120       complete list. However, with the "Wrapper" style things do not work that
 121       way. Because the "install name"s of all frameworks are relative paths,
 122       during linking the mach dyld cannot find the dependend frameworks
 123       (because the path isn't absolute) and thus symbol checking fails. This
 124       directly leads to prebinding to fail which we really don't want since we
 125       have such a huge dependency tree and prebinding escpecially in our case
 126       speeds up loading significantly. So, umbrellas do not really help with
 127       "Wrapper" products - in fact they just add to the overall dependency
 128       graph without providing any benefit. With the notable exception of the
 129       "Development" build style umbrellas are totally useless. If you're
 130       not planning to do a "Wrapper" deployment you might be happy to have
 131       the umbrellas, however, that's why they are still here.
 132
 133 Note: You cannot use the -buildAllTargets commandline argument for Xcode,
 134       because the Xcode projects also contain a target to build in the
 135       gstep-make environment (called GSM:all)
 136
 137
 138 Prebinding Notes
 139 ================
 140
 141 General technical information about prebinding is available from Apple at
 142 http://developer.apple.com/documentation/Performance/Conceptual/LaunchTime/Tasks/Prebinding.html#//apple_ref/doc/uid/20001858.
 143
 144 OGo frameworks currently use the range from 0xC0000000 to 0xCFFFFFFF.
 145
 146 Any questions and feedback regarding our use of this range should go to
 147 Marcus Müller <znek@mulle-kybernetik.com>.
 148
 149
 150 sope-appserver: 0xC3000000 - 0xC5FFFFFF
 151 =======================================
 152
 153 0xC3000000 NGScripting  [REMOVED]
 154 0xC3200000 NGJavaScript [REMOVED]
 155 0xC3400000 NGHttp               [not available in gstep-make]
 156 0xC3700000 WebDAV               [not available in gstep-make]
 157 0xC3A00000 SoOFS                [not available in gstep-make]
 158 0xC3D00000 NGXmlRpc
 159 0xC4000000 WEExtensions
 160 0xC4300000 WOExtensions
 161 0xC4600000 NGObjDOM
 162 0xC4900000 NGObjWeb
 163 0xC5AF0000 SoObjects [NEW]
 164 0xC5B00000 WOXML
 165 0xC5E00000 WEPrototype
 166 0xC5FF0000 SOPE
 167
 168 Note:
 169 =====
 170
 171 js.framework is in ThirdParty, required by NGJavaScript, hence we assign
 172 a prebinding address from our range.