Andrew Schulman wrote: > Several of my packages require multiple patches to compile and run properly in > Cygwin. Instead of maintaining them all together as One Big Patch, I find it > easier to manage them as individual, discrete patch files, and apply them all > at > package build time.
Okay, so these are (mostly) your own custom patches needed to port the code to cygwin, and not "official" patches from somewhere else, like 1) bugfixes taken wholesale from another distro (http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-libs/ncurses/files/) 2) intra-release patches (see ftp://invisible-island.net/ncurses/5.6/) If it were 1) or 2), I'd suggest using PATCH_URI="http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-libs/ncurses/files/ncurses-5.6-build.patch ftp://invisible-island.net/ncurses/5.6/ncurses-5.6-coverity.patch.gz"; etc. Of course, there are a few issues there: a) my example, ncurses, has a LOT (50 or so) "official" patches b) they are all gz-compressed; cygport might not support compressed patches in PATCH_URI So, in fact, for ncurses (where some of the official upstream "patches" are actually shell scripts with shar-compressed patches!) I actually DON'T specify these files in PATCH_URI. Instead, I specify them in SRC_URI, and then use src_unpack_hook to apply (that is, execute!) them. However, that's not the case for your screen port, so...moving on. > I also have extra files, such as README and setup.hint, that I like to just > copy > in before building, instead of maintaining them as patches. Again, this is > easier for me in the long run. Ah. So, what you're really trying to do is automate the procedure of "forward porting" your current changeset to the next release -- whether it's the -NEXT release of the same upstream version, or the -1 release an entirely new upstream version. 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/. > So, in general I include the following code in my .cygport files: > > src_prep_fini_hook () > { > cd "${top}" > > # copy in extra files > if [ -d extras -a "$(ls extras)" ] ; then > __step "Copying in extra files" > cp -a extras/* "${S}" > fi > > # apply patches > if [ -d patches -a "$(ls patches | grep '\.patch$')" ] ; then > __step "Applying patches" > cd "${S}" > cygpatch ${top}/patches/*.patch > fi > } > > The above is from screen-4.0.3-1.cygport. The way *I* would do that, is the following: Assuming Yaakov adopts the custom-cmds patch, I'd include a function in my cygport like so: import_changeset() { # contents of your src_prep_fini_hook } Then, my workflow for a new release would be: $ cp pkg-VER-1.cygport pkg-VER-2.cygport ## notice, there are no existing -2.cygwin.patch or -2.src.patch files $ cygport pkg-VER-2.cygport prep ## so, everything gets unpacked, and mirrored -- but src is identical ## origsrc, because there are no -2.*.patch files $ cygport pkg-VER-2.cygport custom0-import_changeset ## FYI, what I do here is 'cygport pkg-VER-2.cygport oldpatch VER-1' ## but that's because I don't mind "maintaining" any changes that ## don't fall into categories 1) and 2) above as patch files: ## .src.patch and .cygwin.patch $ cygport pkg-VER-2.cygport build install pkg ## etc 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. 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'. > 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. > so there's no conflict. 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. However, <1> would work fine, if you used the custom0-import_changeset method. But, having said all that, I realize I'm now just arguing for using a DIFFERENT non-standard cygport patch. 'Course, that makes sense: my original intent for the custom- stuff was for maintainance -- like running individual components of the cvs testsuite via cygport, etc. Yaakov? Pretty please? -- Chuck
