> Okay, so these are (mostly) your own custom patches needed to port the
> code to cygwin, and not "official" patches from somewhere else
Correct. Or anyway, they're patches that aren't included in the source tarball,
and that I maintain separately as discrete patch files.
> Effectively, you're using
> src_prep_fini_hook() as a "maintainer mode", and "maintainer mode" is
> activated by the presence of ${topdir}/extra/ and ${topdir}/patch/.
Exactly. In fact, it's seemed to me for a long time that there was a need to
separate the set of packager/maintainer commands in cygport, from those a user
wants if they just want to build the package from source.
> $ cygport pkg-VER-2.cygport custom0-import_changeset
Sure, this seems fine, if I understand correctly that it runs my custom
import_changeset() function.
> One advantage of this method is that some other user won't get a
> surprising error if they *happen* to have an extra/ directory present
> when they try to build your package. They'd have to explicitly invoke
> custom0-import_changeset -- and hopefully if they do THAT, then they
> know what they are doing. Your way, random files from their extra/
> directory will automatically get copied in, which could be...unexpected.
Agreed.
> Another advantage -- to my thinking -- is that I *never* import the
> original files from extra/ and patch/ unless I explicitly choose to do
> so; it won't happen by accident. I think that's good; however, you may
> value the "automatic" behavior of embedding this action as part of 'prep'.
I always import patches/ and extra/. It's part of my standard build procedure.
But, it's no big deal to have a separate command for that, if it fits better in
the design of cygport. Although... something with a little shorter name than
custom0-import_changeset would be nice :|
> > Note that the problem you mentioned of the patches being applied twice
> > doesn't
> > occur. If I'm building the packages, then the extras/ and patches/
> > directories
> > are present. Someone else who's building the binary package from source
> > doesn't
> > have those directories
>
> You hope.
No one's complained yet :)
> My typical workflow at present involves doing the following after I'm
> done with development for a new release:
>
> <1>
> $ cygport foo-VER-REL.cygport pkg
> $ tar xvjf foo-VER-REL-src.tar.bz2
> $ cygport foo-VER-REL.cygport finish almostall
>
> So that I am assured that the distributed src package works. With your
> system, you'd have to do
>
> <2>
> $ cygport foo-VER-REL.cygport pkg
> $ mkdir temp
> $ cd temp
> $ tar xvjf ../foo-VER-REL-src.tar.bz2
> $ cygport foo-VER-REL.cygport all
> $ mv *.tar.bz2 ..
> $ cd ..
> $ rmdir temp
>
> to have the same effect. If you did it as in <1> with your
> src_prep_fini_hook, you'd have BOTH the .src.patch and .cygwin.patch
> present, AND the extra/ and patch/ directories. That's not an issue with
> the extra/ files, but the changes represented by patch/* are duplicated
> by the .src.patch changes, and that would definitely bomb out.
Well, that is my problem it seems. I generally don't go back and rebuild the
source package, but when I have I've just moved to a different directory to do
it.
> But, having said all that, I realize I'm now just arguing for using a
> DIFFERENT non-standard cygport patch.
As long as there's some reasonable way to do it, I don't care too much which way
it is.
Thanks to you and Yaakov for looking at this.
Andrew.
