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

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