From 18e7f1b4856517f5716190ff4faafc8a43a2c7ab Mon Sep 17 00:00:00 2001 From: znek Date: Tue, 4 Mar 2008 13:46:32 +0000 Subject: [PATCH] updated git-svn-id: http://svn.opengroupware.org/SOPE/trunk@1610 e4a50df8-12e2-0310-a44c-efbce7f8a7e3 --- sope-appserver/README-OSX.txt | 137 +--------------------------------- sope-gdl1/README-OSX.txt | 108 ++------------------------- sope-ical/README-OSX.txt | 113 ++-------------------------- sope-ldap/README-OSX.txt | 107 ++------------------------ sope-mime/README-OSX.txt | 114 +--------------------------- sope-xml/README-OSX.txt | 116 +--------------------------- 6 files changed, 26 insertions(+), 669 deletions(-) diff --git a/sope-appserver/README-OSX.txt b/sope-appserver/README-OSX.txt index 7768fd20..8cbe70c3 100644 --- a/sope-appserver/README-OSX.txt +++ b/sope-appserver/README-OSX.txt @@ -1,146 +1,17 @@ +Please refer to ../README-OSX.txt for compilation directives. + Building Notes ============== Prerequisites: -- Apple Developer Tools - sope-xml - sope-core -There are two ways to build SOPE on MacOSX, either using the gnustep-make -package or as native Xcode projects. The first option is usually used when -you build SOPE for use with OGo, while the latter is more appropriate for -SOPE:X applications. - -Building using gstep-make: -========================== - -First install gnustep-make (eg v1.10), then ensure that GNUstep.sh is properly -sources. For the build just enter: - make -s install -or - make -s debug=yes install -if you build with debug informations. - -Building using Xcode: -===================== - -The Xcode build comes in two variants, one for development and the other for -deployment. - - -Development ------------ -Development usually means you're happily hacking away at your pet -projects and sometimes want to update the SOPE frameworks. For this purpose -use the "all" target and the accompanied "Development" build style. Later, -you can narrow the target down to something more specific. For development we -assume the destination for frameworks to be /Library/Frameworks. Once you are -done building all the frameworks the loader commands of the frameworks will -have that destination path built in. In order to use the frameworks you either -have to install them (by copying them manually to their destination) or to -prepare symlinks from /Library/Frameworks to the place where the built products -are. I usually build everything in a central place (i.e. /Local/BuildArea) and -have symlinks from /Library/Frameworks to /Local/BuildArea for each of the -products. - -Also the following products are expected to be in the following locations: -*.sax -> /Library/SaxDrivers -*.sxp -> /Library/SoProducts - -Either copy them to the appropriate places or symlink them (my suggestion). - - -Deployment ----------- -Deployment in our terms means you want to copy all required SOPE products into -an application's app wrapper. For this step all frameworks need to be built in -a special fashion, as the "install_name" of the frameworks needs to be prepared -to point to a relative path in the app wrapper. The situation is even more -complicated as all frameworks during linking store the "install names" of other -frameworks in their mach loader commands. In order for this step not to break -we need to set up an environment which is clearly separated from the -Development environment. I chose to use $(USER_LIBRARY_DIR)/EmbeddedFrameworks -as the default destination for these builds. In order for your application to -easily pick up the built products and copy them into its app wrapper this -location needs to be fixed and easily accessible. Note that on my system -~/Library/EmbeddedFrameworks is a symlink to /Library/EmbeddedFrameworks so -even if you don't like the location at all it's very easy to point it to -somewhere else. As soon as you have set this up you can use the -"Wrapper Contents" target with the accompanied "Wrapper" build style to build -all wrapper contents in the appropriate fashion. When you're done you can copy -all the wrapper products into your application's wrapper. The expected -destination is the "Frameworks" directory in the wrappers "Contents" directory. -For a complete list of what you need to copy into your application's wrapper -see the "Direct Dependencies" of all "Wrapper Contents" targets in all SOPE -related projects. At the time of this writing the complete list for SOPE -consisted of the following: - -SxXML - SaxObjC.framework - DOM.framework - XmlRpc.framework - -SxCore - EOControl.framework - EOCoreData.framework - NGExtensions.framework - NGStreams.framework - -NGMime - NGMime.framework - NGMail.framework - NGImap4.framework - -NGiCal.framework - -NGLdap.framework - -SOPE - NGHttp.framework - WebDAV.framework - SoOFS.framework - NGXmlRpc.framework - WOExtensions.framework - WEExtensions.framework - NGObjWeb.framework - - -Note: "A word on umbrellas" - The general idea of umbrellas is to make life easier by providing a cover - for linking. In an ideal world we would provide a SOPE umbrella (we - actually do that) and you just link against that and forget about the - complete list. However, with the "Wrapper" style things do not work that - way. Because the "install name"s of all frameworks are relative paths, - during linking the mach dyld cannot find the dependend frameworks - (because the path isn't absolute) and thus symbol checking fails. This - directly leads to prebinding to fail which we really don't want since we - have such a huge dependency tree and prebinding escpecially in our case - speeds up loading significantly. So, umbrellas do not really help with - "Wrapper" products - in fact they just add to the overall dependency - graph without providing any benefit. With the notable exception of the - "Development" build style umbrellas are totally useless. If you're - not planning to do a "Wrapper" deployment you might be happy to have - the umbrellas, however, that's why they are still here. - -Note: You cannot use the -buildAllTargets commandline argument for Xcode, - because the Xcode projects also contain a target to build in the - gstep-make environment (called GSM:all) - - -Prebinding Notes -================ - -General technical information about prebinding is available from Apple at -http://developer.apple.com/documentation/Performance/Conceptual/LaunchTime/Tasks/Prebinding.html#//apple_ref/doc/uid/20001858. - -OGo frameworks currently use the range from 0xC0000000 to 0xCFFFFFFF. - -Any questions and feedback regarding our use of this range should go to -Marcus Müller . +Prebinding Notes (DEPRECATED, for reference only) +================================================= sope-appserver: 0xC3000000 - 0xC5FFFFFF -======================================= 0xC3000000 NGScripting [REMOVED] 0xC3200000 NGJavaScript [REMOVED] diff --git a/sope-gdl1/README-OSX.txt b/sope-gdl1/README-OSX.txt index 1e2992ff..b02c13df 100644 --- a/sope-gdl1/README-OSX.txt +++ b/sope-gdl1/README-OSX.txt @@ -1,115 +1,17 @@ -# $Id$ +Please refer to ../README-OSX.txt for compilation directives. Building Notes ============== Prerequisites: -- Apple Developer Tools -- skyrix-xml -- skyrix-core +- sope-xml +- sope-core -There are two ways to build SOPE on MacOSX, either using the gnustep-make -package or as native Xcode projects. The first option is usually used when -you build SOPE for use with OGo, while the latter is more appropriate for -SOPE:X applications. - -Building using gstep-make: -========================== - -First install gnustep-make (eg v1.10), then ensure that GNUstep.sh is properly -sourced. For the build just enter: - make -s install -or - make -s debug=yes install -if you build with debug informations. - -Building using Xcode: -===================== - -The Xcode build comes in two variants, one for development and the other for -deployment. - - -Development ------------ -Development usually means you're happily hacking away at your pet -projects and sometimes want to update the SOPE frameworks. For this purpose -use the "all" target and the accompanied "Development" build style. Later, -you can narrow the target down to something more specific. For development we -assume the destination for frameworks to be /Library/Frameworks. Once you are -done building all the frameworks the loader commands of the frameworks will -have that destination path built in. In order to use the frameworks you either -have to install them (by copying them manually to their destination) or to -prepare symlinks from /Library/Frameworks to the place where the built products -are. I usually build everything in a central place (i.e. /Local/BuildArea) and -have symlinks from /Library/Frameworks to /Local/BuildArea for each of the -products. - -Either copy them to the appropriate places or symlink them (my suggestion). - - -Deployment ----------- -Deployment in our terms means you want to copy all required SOPE products into -an application's app wrapper. For this step all frameworks need to be built in -a special fashion, as the "install_name" of the frameworks needs to be prepared -to point to a relative path in the app wrapper. The situation is even more -complicated as all frameworks during linking store the "install names" of other -frameworks in their mach loader commands. In order for this step not to break -we need to set up an environment which is clearly separated from the -Development environment. I chose to use $(USER_LIBRARY_DIR)/EmbeddedFrameworks -as the default destination for these builds. In order for your application to -easily pick up the built products and copy them into its app wrapper this -location needs to be fixed and easily accessible. Note that on my system -~/Library/EmbeddedFrameworks is a symlink to /Library/EmbeddedFrameworks so -even if you don't like the location at all it's very easy to point it to -somewhere else. As soon as you have set this up you can use the -"Wrapper Contents" target with the accompanied "Wrapper" build style to build -all wrapper contents in the appropriate fashion. When you're done you can copy -all the wrapper products into your application's wrapper. The expected -destination is the "Frameworks" directory in the wrappers "Contents" directory. -For a complete list of what you need to copy into your application's wrapper -see the "Direct Dependencies" of all "Wrapper Contents" targets in all SOPE -related projects. At the time of this writing the complete list for SOPE -consisted of the following: - - -Note: "A word on umbrellas" - The general idea of umbrellas is to make life easier by providing a cover - for linking. In an ideal world we would provide a SOPE umbrella (we - actually do that) and you just link against that and forget about the - complete list. However, with the "Wrapper" style things do not work that - way. Because the "install name"s of all frameworks are relative paths, - during linking the mach dyld cannot find the dependend frameworks - (because the path isn't absolute) and thus symbol checking fails. This - directly leads to prebinding to fail which we really don't want since we - have such a huge dependency tree and prebinding escpecially in our case - speeds up loading significantly. So, umbrellas do not really help with - "Wrapper" products - in fact they just add to the overall dependency - graph without providing any benefit. With the notable exception of the - "Development" build style umbrellas are totally useless. If you're - not planning to do a "Wrapper" deployment you might be happy to have - the umbrellas, however, that's why they are still here. - -Note: You cannot use the -buildAllTargets commandline argument for Xcode, - because the Xcode projects also contain a target to build in the - gstep-make environment (called GSM:all) - - -Prebinding Notes -================ - -General technical information about prebinding is available from Apple at -http://developer.apple.com/documentation/Performance/Conceptual/LaunchTime/Tasks/Prebinding.html#//apple_ref/doc/uid/20001858. - -OGo frameworks currently use the range from 0xC0000000 to 0xCFFFFFFF. - -Any questions and feedback regarding our use of this range should go to -Marcus Müller . +Prebinding Notes (DEPRECATED, for reference only) +================================================= sope-gdl1: 0xC6000000 - 0xC6FFFFFF -================================== 0xC6000000 GDLAccess 0xC6FF0000 ??? diff --git a/sope-ical/README-OSX.txt b/sope-ical/README-OSX.txt index de9b41cb..6ae48ecb 100644 --- a/sope-ical/README-OSX.txt +++ b/sope-ical/README-OSX.txt @@ -1,119 +1,16 @@ +Please refer to ../README-OSX.txt for compilation directives. + Building Notes ============== Prerequisites: -- Apple Developer Tools - sope-xml - sope-core -There are two ways to build SOPE on MacOSX, either using the gnustep-make -package or as native Xcode projects. The first option is usually used when -you build SOPE for use with OGo, while the latter is more appropriate for -SOPE:X applications. - -Building using gstep-make: -========================== - -First install gnustep-make (eg v1.8), then ensure that GNUstep.sh is properly -sources. For the build just enter: - make -s install -or - make -s debug=yes install -if you build with debug informations. - -Building using Xcode: -===================== - -The Xcode build comes in two variants, one for development and the other for -deployment. - - -Development ------------ -Development usually means you're happily hacking away at your pet -projects and sometimes want to update the SOPE frameworks. For this purpose -use the "all" target and the accompanied "Development" build style. Later, -you can narrow the target down to something more specific. For development we -assume the destination for frameworks to be /Library/Frameworks. Once you are -done building all the frameworks the loader commands of the frameworks will -have that destination path built in. In order to use the frameworks you either -have to install them (by copying them manually to their destination) or to -prepare symlinks from /Library/Frameworks to the place where the built products -are. I usually build everything in a central place (i.e. /Local/BuildArea) and -have symlinks from /Library/Frameworks to /Local/BuildArea for each of the -products. - -Also the following products are expected to be in the following locations: -*.sax -> /Library/SaxDrivers -*.sxp -> /Library/SoProducts - -Either copy them to the appropriate places or symlink them (my suggestion). - - -Deployment ----------- -Deployment in our terms means you want to copy all required SOPE products into -an application's app wrapper. For this step all frameworks need to be built in -a special fashion, as the "install_name" of the frameworks needs to be prepared -to point to a relative path in the app wrapper. The situation is even more -complicated as all frameworks during linking store the "install names" of other -frameworks in their mach loader commands. In order for this step not to break -we need to set up an environment which is clearly separated from the -Development environment. I chose to use $(USER_LIBRARY_DIR)/EmbeddedFrameworks -as the default destination for these builds. In order for your application to -easily pick up the built products and copy them into its app wrapper this -location needs to be fixed and easily accessible. Note that on my system -~/Library/EmbeddedFrameworks is a symlink to /Library/EmbeddedFrameworks so -even if you don't like the location at all it's very easy to point it to -somewhere else. As soon as you have set this up you can use the -"Wrapper Contents" target with the accompanied "Wrapper" build style to build -all wrapper contents in the appropriate fashion. When you're done you can copy -all the wrapper products into your application's wrapper. The expected -destination is the "Frameworks" directory in the wrappers "Contents" directory. -For a complete list of what you need to copy into your application's wrapper -see the "Direct Dependencies" of all "Wrapper Contents" targets in all SOPE -related projects. At the time of this writing the complete list for SOPE -consisted of the following: - -sope-ical - NGiCal.framework - - -Note: "A word on umbrellas" - The general idea of umbrellas is to make life easier by providing a cover - for linking. In an ideal world we would provide a SOPE umbrella (we - actually do that) and you just link against that and forget about the - complete list. However, with the "Wrapper" style things do not work that - way. Because the "install name"s of all frameworks are relative paths, - during linking the mach dyld cannot find the dependend frameworks - (because the path isn't absolute) and thus symbol checking fails. This - directly leads to prebinding to fail which we really don't want since we - have such a huge dependency tree and prebinding escpecially in our case - speeds up loading significantly. So, umbrellas do not really help with - "Wrapper" products - in fact they just add to the overall dependency - graph without providing any benefit. With the notable exception of the - "Development" build style umbrellas are totally useless. If you're - not planning to do a "Wrapper" deployment you might be happy to have - the umbrellas, however, that's why they are still here. - -Note: You cannot use the -buildAllTargets commandline argument for Xcode, - because the Xcode projects also contain a target to build in the - gstep-make environment (called GSM:all) - - -Prebinding Notes -================ - -General technical information about prebinding is available from Apple at -http://developer.apple.com/documentation/Performance/Conceptual/LaunchTime/Tasks/Prebinding.html#//apple_ref/doc/uid/20001858. - -OGo frameworks currently use the range from 0xC0000000 to 0xCFFFFFFF. - -Any questions and feedback regarding our use of this range should go to -Marcus Müller . +Prebinding Notes (DEPRECATED, for reference only) +================================================= -SxCore: 0xC1000000 - 0xC2FFFFFF -=============================== +sope-core: 0xC1000000 - 0xC2FFFFFF 0xC1E00000 NGiCal diff --git a/sope-ldap/README-OSX.txt b/sope-ldap/README-OSX.txt index 66b794c5..7b608968 100644 --- a/sope-ldap/README-OSX.txt +++ b/sope-ldap/README-OSX.txt @@ -1,113 +1,16 @@ +Please refer to ../README-OSX.txt for compilation directives. + Building Notes ============== Prerequisites: -- Apple Developer Tools - sope-xml - sope-core -There are two ways to build SOPE on MacOSX, either using the gnustep-make -package or as native Xcode projects. The first option is usually used when -you build SOPE for use with OGo, while the latter is more appropriate for -SOPE:X applications. - -Building using gstep-make: -========================== - -First install gnustep-make (eg v1.8), then ensure that GNUstep.sh is properly -sources. For the build just enter: - make -s install -or - make -s debug=yes install -if you build with debug informations. - -Building using Xcode: -===================== - -The Xcode build comes in two variants, one for development and the other for -deployment. - - -Development ------------ -Development usually means you're happily hacking away at your pet -projects and sometimes want to update the SOPE frameworks. For this purpose -use the "all" target and the accompanied "Development" build style. Later, -you can narrow the target down to something more specific. For development we -assume the destination for frameworks to be /Library/Frameworks. Once you are -done building all the frameworks the loader commands of the frameworks will -have that destination path built in. In order to use the frameworks you either -have to install them (by copying them manually to their destination) or to -prepare symlinks from /Library/Frameworks to the place where the built products -are. I usually build everything in a central place (i.e. /Local/BuildArea) and -have symlinks from /Library/Frameworks to /Local/BuildArea for each of the -products. - - -Deployment ----------- -Deployment in our terms means you want to copy all required SOPE products into -an application's app wrapper. For this step all frameworks need to be built in -a special fashion, as the "install_name" of the frameworks needs to be prepared -to point to a relative path in the app wrapper. The situation is even more -complicated as all frameworks during linking store the "install names" of other -frameworks in their mach loader commands. In order for this step not to break -we need to set up an environment which is clearly separated from the -Development environment. I chose to use $(USER_LIBRARY_DIR)/EmbeddedFrameworks -as the default destination for these builds. In order for your application to -easily pick up the built products and copy them into its app wrapper this -location needs to be fixed and easily accessible. Note that on my system -~/Library/EmbeddedFrameworks is a symlink to /Library/EmbeddedFrameworks so -even if you don't like the location at all it's very easy to point it to -somewhere else. As soon as you have set this up you can use the -"Wrapper Contents" target with the accompanied "Wrapper" build style to build -all wrapper contents in the appropriate fashion. When you're done you can copy -all the wrapper products into your application's wrapper. The expected -destination is the "Frameworks" directory in the wrappers "Contents" directory. -For a complete list of what you need to copy into your application's wrapper -see the "Direct Dependencies" of all "Wrapper Contents" targets in all SOPE -related projects. At the time of this writing the complete list for SOPE -consisted of the following: - -sope-ldap - NGLdap.framework - - -Note: "A word on umbrellas" - The general idea of umbrellas is to make life easier by providing a cover - for linking. In an ideal world we would provide a SOPE umbrella (we - actually do that) and you just link against that and forget about the - complete list. However, with the "Wrapper" style things do not work that - way. Because the "install name"s of all frameworks are relative paths, - during linking the mach dyld cannot find the dependend frameworks - (because the path isn't absolute) and thus symbol checking fails. This - directly leads to prebinding to fail which we really don't want since we - have such a huge dependency tree and prebinding escpecially in our case - speeds up loading significantly. So, umbrellas do not really help with - "Wrapper" products - in fact they just add to the overall dependency - graph without providing any benefit. With the notable exception of the - "Development" build style umbrellas are totally useless. If you're - not planning to do a "Wrapper" deployment you might be happy to have - the umbrellas, however, that's why they are still here. - -Note: You cannot use the -buildAllTargets commandline argument for Xcode, - because the Xcode projects also contain a target to build in the - gstep-make environment (called GSM:all) - - -Prebinding Notes -================ - -General technical information about prebinding is available from Apple at -http://developer.apple.com/documentation/Performance/Conceptual/LaunchTime/Tasks/Prebinding.html#//apple_ref/doc/uid/20001858. - -OGo frameworks currently use the range from 0xC0000000 to 0xCFFFFFFF. - -Any questions and feedback regarding our use of this range should go to -Marcus Müller . +Prebinding Notes (DEPRECATED, for reference only) +================================================= -SxCore: 0xC1000000 - 0xC2FFFFFF -=============================== +sope-core: 0xC1000000 - 0xC2FFFFFF 0xC1C00000 NGLdap diff --git a/sope-mime/README-OSX.txt b/sope-mime/README-OSX.txt index 9425090e..5127f173 100644 --- a/sope-mime/README-OSX.txt +++ b/sope-mime/README-OSX.txt @@ -1,123 +1,17 @@ -# $Id: README-OSX.txt 4 2004-08-20 17:04:31Z helge $ +Please refer to ../README-OSX.txt for compilation directives. Building Notes ============== Prerequisites: -- Apple Developer Tools - sope-xml - sope-core -There are two ways to build SOPE on MacOSX, either using the gnustep-make -package or as native Xcode projects. The first option is usually used when -you build SOPE for use with OGo, while the latter is more appropriate for -SOPE:X applications. -Building using gstep-make: -========================== +Prebinding Notes (DEPRECATED, for reference only) +================================================= -First install gnustep-make (eg v1.8), then ensure that GNUstep.sh is properly -sources. For the build just enter: - make -s install -or - make -s debug=yes install -if you build with debug informations. - -Building using Xcode: -===================== - -The Xcode build comes in two variants, one for development and the other for -deployment. - - -Development ------------ -Development usually means you're happily hacking away at your pet -projects and sometimes want to update the SOPE frameworks. For this purpose -use the "all" target and the accompanied "Development" build style. Later, -you can narrow the target down to something more specific. For development we -assume the destination for frameworks to be /Library/Frameworks. Once you are -done building all the frameworks the loader commands of the frameworks will -have that destination path built in. In order to use the frameworks you either -have to install them (by copying them manually to their destination) or to -prepare symlinks from /Library/Frameworks to the place where the built products -are. I usually build everything in a central place (i.e. /Local/BuildArea) and -have symlinks from /Library/Frameworks to /Local/BuildArea for each of the -products. - -Also the following products are expected to be in the following locations: -*.sax -> /Library/SaxDrivers -*.sxp -> /Library/SoProducts - -Either copy them to the appropriate places or symlink them (my suggestion). - - -Deployment ----------- -Deployment in our terms means you want to copy all required SOPE products into -an application's app wrapper. For this step all frameworks need to be built in -a special fashion, as the "install_name" of the frameworks needs to be prepared -to point to a relative path in the app wrapper. The situation is even more -complicated as all frameworks during linking store the "install names" of other -frameworks in their mach loader commands. In order for this step not to break -we need to set up an environment which is clearly separated from the -Development environment. I chose to use $(USER_LIBRARY_DIR)/EmbeddedFrameworks -as the default destination for these builds. In order for your application to -easily pick up the built products and copy them into its app wrapper this -location needs to be fixed and easily accessible. Note that on my system -~/Library/EmbeddedFrameworks is a symlink to /Library/EmbeddedFrameworks so -even if you don't like the location at all it's very easy to point it to -somewhere else. As soon as you have set this up you can use the -"Wrapper Contents" target with the accompanied "Wrapper" build style to build -all wrapper contents in the appropriate fashion. When you're done you can copy -all the wrapper products into your application's wrapper. The expected -destination is the "Frameworks" directory in the wrappers "Contents" directory. -For a complete list of what you need to copy into your application's wrapper -see the "Direct Dependencies" of all "Wrapper Contents" targets in all SOPE -related projects. At the time of this writing the complete list for SOPE -consisted of the following: - -sope-mime - NGMime.framework - NGMail.framework - NGImap4.framework - -Note: "A word on umbrellas" - The general idea of umbrellas is to make life easier by providing a cover - for linking. In an ideal world we would provide a SOPE umbrella (we - actually do that) and you just link against that and forget about the - complete list. However, with the "Wrapper" style things do not work that - way. Because the "install name"s of all frameworks are relative paths, - during linking the mach dyld cannot find the dependend frameworks - (because the path isn't absolute) and thus symbol checking fails. This - directly leads to prebinding to fail which we really don't want since we - have such a huge dependency tree and prebinding escpecially in our case - speeds up loading significantly. So, umbrellas do not really help with - "Wrapper" products - in fact they just add to the overall dependency - graph without providing any benefit. With the notable exception of the - "Development" build style umbrellas are totally useless. If you're - not planning to do a "Wrapper" deployment you might be happy to have - the umbrellas, however, that's why they are still here. - -Note: You cannot use the -buildAllTargets commandline argument for Xcode, - because the Xcode projects also contain a target to build in the - gstep-make environment (called GSM:all) - - -Prebinding Notes -================ - -General technical information about prebinding is available from Apple at -http://developer.apple.com/documentation/Performance/Conceptual/LaunchTime/Tasks/Prebinding.html#//apple_ref/doc/uid/20001858. - -OGo frameworks currently use the range from 0xC0000000 to 0xCFFFFFFF. - -Any questions and feedback regarding our use of this range should go to -Marcus Müller . - - -SxCore: 0xC1000000 - 0xC2FFFFFF -=============================== +sope-core: 0xC1000000 - 0xC2FFFFFF 0xC1600000 NGImap4 [not available with gstep-make] 0xC1800000 NGMail [not available with gstep-make] diff --git a/sope-xml/README-OSX.txt b/sope-xml/README-OSX.txt index 3da098ce..8c559ce9 100644 --- a/sope-xml/README-OSX.txt +++ b/sope-xml/README-OSX.txt @@ -1,119 +1,9 @@ -Building Notes -============== - -Prerequisites: -- Apple Developer Tools - -There are two ways to build SOPE on MacOSX, either using the gnustep-make -package or as native Xcode projects. The first option is usually used when -you build SOPE for use with OGo, while the latter is more appropriate for -SOPE:X applications. - -Building using gstep-make: -========================== - -First install gnustep-make (eg v1.8), then ensure that GNUstep.sh is properly -sources. For the build just enter: - make -s install -or - make -s debug=yes install -if you build with debug informations. - -Building using Xcode: -===================== - -The Xcode build comes in two variants, one for development and the other for -deployment. - - -Development ------------ -Development usually means you're happily hacking away at your pet -projects and sometimes want to update the SOPE frameworks. For this purpose -use the "all" target and the accompanied "Development" build style. Later, -you can narrow the target down to something more specific. For development we -assume the destination for frameworks to be /Library/Frameworks. Once you are -done building all the frameworks the loader commands of the frameworks will -have that destination path built in. In order to use the frameworks you either -have to install them (by copying them manually to their destination) or to -prepare symlinks from /Library/Frameworks to the place where the built products -are. I usually build everything in a central place (i.e. /Local/BuildArea) and -have symlinks from /Library/Frameworks to /Local/BuildArea for each of the -products. - -Also the following products are expected to be in the following locations: -*.sax -> /Library/SaxDrivers -*.sxp -> /Library/SoProducts - -Either copy them to the appropriate places or symlink them (my suggestion). - - -Deployment ----------- -Deployment in our terms means you want to copy all required SOPE products into -an application's app wrapper. For this step all frameworks need to be built in -a special fashion, as the "install_name" of the frameworks needs to be prepared -to point to a relative path in the app wrapper. The situation is even more -complicated as all frameworks during linking store the "install names" of other -frameworks in their mach loader commands. In order for this step not to break -we need to set up an environment which is clearly separated from the -Development environment. I chose to use $(USER_LIBRARY_DIR)/EmbeddedFrameworks -as the default destination for these builds. In order for your application to -easily pick up the built products and copy them into its app wrapper this -location needs to be fixed and easily accessible. Note that on my system -~/Library/EmbeddedFrameworks is a symlink to /Library/EmbeddedFrameworks so -even if you don't like the location at all it's very easy to point it to -somewhere else. As soon as you have set this up you can use the -"Wrapper Contents" target with the accompanied "Wrapper" build style to build -all wrapper contents in the appropriate fashion. When you're done you can copy -all the wrapper products into your application's wrapper. The expected -destination is the "Frameworks" directory in the wrappers "Contents" directory. -For a complete list of what you need to copy into your application's wrapper -see the "Direct Dependencies" of all "Wrapper Contents" targets in all SOPE -related projects. At the time of this writing the complete list for SxXML -consisted of the following: - -sope-xml.framework - SaxObjC.framework - DOM.framework - XmlRpc.framework - -Note: "A word on umbrellas" - The general idea of umbrellas is to make life easier by providing a cover - for linking. In an ideal world we would provide a SOPE umbrella (we - actually do that) and you just link against that and forget about the - complete list. However, with the "Wrapper" style things do not work that - way. Because the "install name"s of all frameworks are relative paths, - during linking the mach dyld cannot find the dependend frameworks - (because the path isn't absolute) and thus symbol checking fails. This - directly leads to prebinding to fail which we really don't want since we - have such a huge dependency tree and prebinding escpecially in our case - speeds up loading significantly. So, umbrellas do not really help with - "Wrapper" products - in fact they just add to the overall dependency - graph without providing any benefit. With the notable exception of the - "Development" build style umbrellas are totally useless. If you're - not planning to do a "Wrapper" deployment you might be happy to have - the umbrellas, however, that's why they are still here. - -Note: You cannot use the -buildAllTargets commandline argument for Xcode, - because the Xcode projects also contain a target to build in the - gstep-make environment (called GSM:all) - - -Prebinding Notes -================ - -General technical information about prebinding is available from Apple at -http://developer.apple.com/documentation/Performance/Conceptual/LaunchTime/Tasks/Prebinding.html#//apple_ref/doc/uid/20001858. - -OGo frameworks currently use the range from 0xC0000000 to 0xCFFFFFFF. - -Any questions and feedback regarding our use of this range should go to -Marcus Müller . +Please refer to ../README-OSX.txt for compilation directives. +Prebinding Notes (DEPRECATED, for reference only) +================================================= sope-xml: 0xC0000000 - 0xC0FFFFFF -================================= 0xC0000000 SaxObjC 0xC0200000 DOM -- 2.39.5