[SmartcardServices-Dev] Proposal for patching and maintaining the main source repository

[William Siegrist]

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  
look like:

# 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/ 
path/to/file.c
... 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   ./  > ~/ 
SmartCardServices_MyFix.patch


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.


Thanks
-Bill