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
