From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29759 invoked by alias); 8 Nov 2008 01:38:36 -0000 Received: (qmail 29676 invoked by uid 22791); 8 Nov 2008 01:38:34 -0000 X-Spam-Check-By: sourceware.org Received: from out5.smtp.messagingengine.com (HELO out5.smtp.messagingengine.com) (66.111.4.29) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 08 Nov 2008 01:36:58 +0000 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id EF4CD1A33C4 for ; Fri, 7 Nov 2008 20:36:55 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 07 Nov 2008 20:36:55 -0500 Received: from [192.168.1.3] (user-0cej09l.cable.mindspring.com [24.233.129.53]) by mail.messagingengine.com (Postfix) with ESMTPSA id 883AF29FE5; Fri, 7 Nov 2008 20:36:55 -0500 (EST) Message-ID: <4914ED2E.3000106@cwilson.fastmail.fm> Date: Sat, 08 Nov 2008 01:38:00 -0000 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.17) Gecko/20080914 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Mailing List: CygWin-Apps Subject: Re: cygport-0.9.3 in release-2 References: <4906B2F8.4000708@users.sourceforge.net> <747eg4dsfpl4befpo8gb4qkgo3sm0d8fbi@4ax.com> <747eg4dsfpl4befpo8gb4qkgo3sm0d8fbi-e09XROE/p8c@public.gmane.org> <4907C0F1.2040005@cwilson.fastmail.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com X-SW-Source: 2008-11/txt/msg00057.txt.bz2 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