cygport and CYGWIN-PATCHES

[Charles Wilson]

Warren Young wrote:
> Yaakov (Cygwin Ports) wrote:
>> | Is there a way I can get Cygport to generate this patch for me?
>> You need to put these files into foo-ver-rel/CYGWIN-PATCHES/.
> 
> I actually stumbled across that earlier, but I convinced myself it 
> couldn't be the right way to do it.

Just try it.

> foo-ver-rel doesn't exist until after prep, so to copy these files in, 
> you have to run the prep...finish steps by hand, so you can insert them 
> between prep and compile, right? 

Yes.  Most of the time, almostall and all are /not/ for maintainers. 
They are for /other/ people, who for whatever reason want to build their 
own version. Maybe he edited the cygport file to add a different 
configure option -- or maybe his name is Volker Zell and he's testing 
your package after an ITP.

> I'm getting hung up on the existence 
> of the almostall and all commands: what's their value if you have to do 
> something outside of cygport between prep and compile?

I use 'all' only as a final step before uploading.  I've already done 
(incrementally, maybe several iterations) lots of 'build' and 'install' 
and 'pkg'...and then I noticed a problem, so I go fix it and try 'build' 
again.  And then there's that new doc file, so I edit the src_install 
for this release, and do 'install' and 'pkg' again...

After all that, it's a nice check to do:

cygport foo.cygport pkg
tar xvjf foo-src.tar.bz2
cygport foo.cygport finish
cygport foo.cygport almostall (or all)

I usually use 'almostall' because (a) I'm pretty sure I can't break 
'finish', and (b) that way, I still have the handy /dist directory for 
easy uploading.

I also use almostall when I'm about to start a new update:

cp foo-OLD.cygport foo-NEW.cygport
cp foo-OLD.src.patch foo-NEW.src.patch
cp foo-OLD.cygwin.patch foo-NEW.cygwin.patch
cygport foo-NEW.cygport almostall

and, if everything went well, I now how completely built version of 
foo-NEW to make my changes in...without clobbering my foo-OLD stuff.

> If cygport can do these steps for you, then I see the point of almostall 
> and all again.  If it doesn't do these things for you now, will you 
> accept a patch to make it do so?

To do...what, exactly?  The *first* time, when you're initially creating 
a brand new cygport, things are a little odd. How is cygport supposed to 
create, ex nihilo, your custom README and custom .hint files, and put 
them into CYGWIN-PATCHES? they don't exist, yet, at all. You have to 
write them.

Same thing with src patches? How is cygport suppost to know what patches 
are necessary to make your package compile on cygwin? You have to edit 
the src.

So, for a brand new cygport, you do
(a) cp /usr/share/cygport/sample.cygport foo-1.2.3-1.cygport
(b) edit your .cygport as needed. In this early stage, the most you'll 
probably have to do is fix SRC_DIR, and the various 
download/homepage/description entries.  That's enough for 'prep' to 
create a "blank slate" for you to work on.

cygport foo-1.2.3.cygport prep

(c) Then, once you've done that -- create your
   foo-1.2.3-1/CYGWIN-PATCHES/<stuff>
and edited the src code as appropriate in
   foo-1.2.3-1/src/foo-1.2.3/
so that 'build' and 'install' work the way you want them to (which may 
involve editing the .cygport again, and maybe customizing src_compile() 
and src_install()).

(d) you can do 'pkg' -- which will create, among other things,
   foo-1.2.3-1.src.patch
   foo-1.2.3-1.cygwin.patch
and then stuff them into a
   foo-1.2.3-1-src.tar.bz2

unpack THAT (or look in foo-1.2.3-1/patches/, and you now have your two 
patches. The .src.patch contains all of your changes to the source 
directory, excluding anything under CYGWIN-PATCHES.  The .cygwin.patch 
contains the full contents of all those new files you put into 
CYGWIN-PATCHES the first time around.

Now, 'cygport all' will just work. Hopefully.

--
Chuck