[SmartcardServices-Dev] Proposal for patching and maintaining the main source repository
wsiegrist at apple.com
Thu Jul 9 18:05:02 PDT 2009
Getting the source in the subversion repo to build is a little
trickier that just checking it out and using Xcode. It is basically
identical to what was released with 9J61, which means it requires a
lot of extra stuff that is not in your retail copy of Leopard. So what
I am proposing is using darwinbuild to continue patching and building
the source. I think it'll be the easiest way to take contributions
back from the public and keep things building. If you have another
suggestion, please let us know.
The SmartCardServices project on Mac OS Forge would provide a plist, a
set of patches, and (optionally) a tarball of source. A typical
workflow that contributes back a patch for SmartCardServices would
# download the custom plist with curl or svn
$ curl -LO http://svn.macosforge.org/repository/smartcardservices/trunk/plists/scs_leopard.plist
# make a new environment
$ mkdir ~/scsleo && cd ~/scsleo
$ sudo darwinbuild -init ~/scs_leopard.plist
... watch darwinbuild fetch the other plists you need ...
$ sudo darwinbuild SmartCardServices
... watch it load all the roots you need ...
... watch it build ...
# save the original source to diff later
$ cd BuildRoot/SourceCache/SmartCardServices/
$ cp -R SmartCardServices-34733 SmartCardServices-34733.orig
$ cd ../../..
# make your changes
$ vi BuildRoot/SourceCache/SmartCardServices/SmartCardServices-34733/
... edit more files as needed ...
# try to build your changes
# using -nosource is important as it tells darwinbuild to not
overwrite your changes to the source cache
$ darwinbuild -nosource SmartCardServices
... watch it build your modified source ...
... edit more files, repeat as necessary ...
# create your patchfile
$ cd BuildRoot/SourceCache/SmartCardServices/SmartCardServices-34733/
$ diff -ru ../SmartCardServices-34733.orig ./ > ~/
Then you submit the patch to the project. When accepted, the project
committers would need to modify the plist to include that patch
filename and commit the new plist plus patch to the subversion
repository (perhaps under trunk/plists and trunk/patches). Then the
next person to perform the above workflow gets the new plist which
uses the new patch.
Note that this method does not use the source in the subversion repo.
What could happen periodically is all of the patches get applied to
the subversion repo and a new tarball is generated. Then the plist is
modified to point to the new tarball and no patches.
If you have any suggestions or opinions about working on the source in
this manner, let us know.
More information about the SmartcardServices-Dev