Re: Re: Idea: embed patch in .info

Benjamin Reed said:
: Daniel Macks wrote:
: 
: > Patch-tracker #768801.
: 
: Normally when I'm porting something, I'll put together a basic info 
: file, go to another window, build it, and wait for it to die.  I go in, 
: make some changes, and generate a patch:
: 
:    diff -uNr foo-pristine foo > /path/too/foo.patch
: 
: Then I build again, and start over.  If there's something wrong, I run 
: the diff again.
: 
: If patches are embedded in the info file, every time I want to generate 
: a patch I need to delete the patch at the end of the info, close the 
: info file, generate the patch, and then re-edit the info file to make 
: other changes.

No reason you can't still do this, and treat the embedding as a last-
minute detail after the whole package is working and ready to go. Then
just change %a to %A and stuff the .patch onto the end of .info. I agree
that it makes generating the *next* revision an extra step or two
(re-change %A->%a, rip off the old patch) unless you remembered to keep
the parent file.

: Not only that, but now we're relying on patch not accidentally thinking 
: anything in the info file is a directive to start a patch (I don't know 
: if it's been done, but I can imagine bits of diff being part of a 
: "DescPort" comment or something similar).

My previous approach was to have the new percent-expand yield a shell 
command that would give the patch data on STDOUT, so then one could
  PatchScript: %[newthing] | patch -p1
and let fink snip off all of the .info before the stop-codon. But I didn't
like having a weird new percent type (command vs. string) and in
particular it would be less of a drop-in replacement for a .patch file.

dan

-- 
Daniel Macks
dmacks@xxxxxxxxxxxx
http://www.netspace.org/~dmacks



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1