This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygport-0.9.3 in release-2


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]