This is the mail archive of the cygwin 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: [patch] cygport-0.2.7 mixed-mode SRC_URIs


Charles Wilson wrote:

If THAT doesn't exercise the mixed-mode patch, nothin' will.

Except that it also uses the src_prep_init_hook changes. Which only makes sense: if you download third-party or upstream patches, somehow you've got to "do" something with them. PATCH_URI helps, but in this case the lossless-jpeg "patch" contains binary images that must be copied into src/ somehow. And that's what the jpeg.cygport does in src_prep_init_hook.


I could probably simplify jpeg.cygport's src_prep_init_hook() a little bit by putting
${origsrcdir}/ljpeg-6b.patch
${origsrcdir}/100_crop.patch
${origsrcdir}/200_crop_man.patch
${origsrcdir}/201_rdjpgcom_locale.patch
${origsrcdir}/202_jpeglib.h_c++.patch
${origsrcdir}/203_rdppm.patch
${origsrcdir}/204_exif_extra.patch
into PATCH_URI, but that still leaves the following in src_prep_init_hook():
cd ${origsrcdir}
mv testimgl* ${SRC_DIR}/
cd ${SRC_DIR}
But those images are only needed by src_test().


However, the above procedure doesn't work, because:
   (1) the two "extra" tarballs are unpacked into ${origsrcdir}

(2) cygport strips directory specifiers from PATCH_URIs:

for _patch_uri in ${PATCH_URI}
do
        _src_orig_patches="${_src_orig_patches} ${_patch_uri##*/}";
done

       and for good reason, too! Those PATCH_URIs might have http://
       or worse in them.

   (3) _src_orig_patches therefore contains "bare" filenames with no
       directory, and apply_patch is called as:

        for src_patch in ${_src_orig_patches}
        do
                apply_patch ${top}/${src_patch};
        done

I don't see either of those for-loops being changed, because they do what they do for very good reasons; changing their behavior would break lots of stuff. Maybe:

        for src_patch in ${_src_orig_patches}
        do
		if [ -e ${origsrcdir}/${src_patch} ]
		then
			apply_patch ${origsrcdir}/${src_patch}
		else
	                apply_patch ${top}/${src_patch};
		fi
        done

But what if your third-party tarball contained:

one-patch
two/another-patch
three/yet-one-more-patch

So, even if jpeg.cygport uses PATCH_URI as above, it'd still need a src_prep_init_hook() function to move the patches from ${origsrcdir} to ${T}. Frankly, I'd prefer to keep them in ${origsrcdir} and call apply_patch -- for THOSE patches -- explicitly, if I'm gonna have a src_prep_init_hook() anyway.

When you're ready for another test case for one of the other patches, let me know.

Sorry, didn't see the next message you sent asking for an demo of the "hooks" stuff. Obviously the mixed-mode-demo patch will do so for the src_prep_*_hooks, but I'll send a demo that needs the src_install_*_hooks in a separate message...


--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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