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

[William Siegrist]

On Jul 21, 2009, at 8:38 AM, Ludovic Rousseau wrote:

> 2009/7/10 William Siegrist <wsiegrist at apple.com>:
>> 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
>
> I can't find this file. Can you create it?
>
> Maybe each sub project (SmartcardCCID  SmartCardServices  Tokend)
> should have a plists directory and the plist names could be
> leopard.plist (without the obscure "scs_")
>
> Something like:
> smartcardservices/trunk/SmartCardServices/plists/leopard.plist
> smartcardservices/trunk/SmartcardCCID/plists/leopard.plist
> smartcardservices/trunk/Tokend/plists/leopard.plist
>

Yes, I can create the initial plist. The "scs" was used in this  
example since the Mac OS Forge project is "Smartcard Services", but  
the name of the plist does not matter. Though, it should not match one  
of the built-in plists which are named after build numbers  
(9G55.plist, 9J61.plist, etc).

The plist can contain all 3 projects, or each sub project can have  
their own. I think having 1 plist is easier, but I'm not the one doing  
the development.


>> 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.
>
> Working directly with subversion would be great. But it looks like it
> is difficult :-(


Thats the conclusion John and I came to as well.  But after some  
thought, I believe we could use an svn working copy inside the  
BuildRoot. So instead of an initial "darwinbuild SmartCardServices" to  
download the tarball and patches, you do a "svn co ..." then the usual  
"darwinbuild -nosource ...". I'll have to test my idea first, but if  
it works, I'll post a new example workflow that would allow directly  
committing to svn.  This might even eliminate the need for a custom  
plist, as long as you don't need to modify what dependencies are in  
the standard 9J61.plist.

-Bill