Andrew Schulman wrote:
> As I explained in the thread referenced above, src_patch_hook() and
> src_unpack_hook() are not adequate substitutes for src_prep_fini_hook(),
> because
> both of the former act *before* origsrc is mirrored to src. So, using them it
> is not possible to make changes to src independently from origsrc.
This is true. In general, changing src independently of origsrc is what
.src.patch and cygwin.patch are for. The only thing you really can't
do via a patch at that point, is to chmod any files created by those
patches (pre-existing files can be chmoded in src_unpack_hook before
patching them). And as Yaakov has pointed out, there's also no reason
why you can't do those chmods in src_compile(), except for aesthetic
reasons ("setting up your src tree is part of prep, not build").
> src_prep_fini_hook(), as Charles proposed it, is called after origsrc is
> mirrored to src, so that I can patch src independent of origsrc, and the
> changes
> are captured in cygwin.patch-- which is essential for creating a working
> source
> package.
This I don't get. Once you've captured the desired differences between
origsrc and src in .src.patch and .cygwin.patch...you are done. Those
patches can be used to regenerate your entire build environment: "mirror
(the possibly src_unpack_hook() and PATCH_URI-modified) origsrc and
then apply the standard two patches". But if you try to rebuild using a
.cygport that specifies BOTH src_prep_fini_hook() AND a .*.patch file
that "captures" those same changes...BOOM: "target already contains
changes; reverse?"
> If you don't like src_prep_fini_hook(), then maybe src_unpack_hook() could be
> moved down below the call to rsync, which would make it the same as
> src_prep_fini_hook().
Uhm, please no. src_unpack_hook() is Yaakov's replacement for the first
half of my original hooks patch, src_prep_init_hook(). THAT one is
needed for LOTS of reasons -- mostly, when you have big changes you want
to make to the origsrc tree precisely because it occurs before mirroring
(such as rearranging files) -- that would otherwise require really
gigantic .src.patch files. In the past, src_prep_init_hook ne'
src_unpack_hook was also used to apply "upstream" standard patches, when
the cygwin maintainer wants to keep them "unbundled" from
cygwin-specific changes to the src (e.g. smaller .src.patch). However,
with the advent of PATCH_URI, "apply standard upstream patches" is not
as large a use ccase for src_unpack_hook().
Andrew, please post one of your .cygports that actually requires the
src_prep_fini_hook(). I'd like to reach a resolution on this (these)
issues, so I can either drop the patches entirely or get some
replacement/reimplementation in cygport.
FYI, the patch set I posted yesterday does NOT include
src_prep_fini_hook(). It only includes src_postinst_hook().
Yaakov is strongly opposed to src_prep_fini_hook(), and I'm more-or-less
convinced that it is not necessary, as well. I'd like to see an actual
example where it is the only solution -- or demonstrating that other
workarounds are significantly inelegant.
With regards to src_postinst_hook() ... well, Yaakov and I can argue
about that in another subthread.
--
Chuck
