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


> 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.


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