← Back to branch summary

~ubuntu-branches/ubuntu/edgy/sope/edgy

« back to all changes in this revision

Viewing changes to sope-ldap/README-OSX.txt

  • Committer: Bazaar Package Importer
  • Author(s): Sebastian Ley
  • Date: 2005-08-19 16:53:31 UTC
  • Revision ID: james.westby@ubuntu.com-20050819165331-hs683wz1osm708pw
Tags: upstream-4.4rc.2
Import upstream version 4.4rc.2

Show diffs side-by-side

added added

removed removed

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