This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: [ITP] libungif-4.1.0-2
Lapo Luchini wrote:
You should either
1) change mkpatch() to only create a diff between your populated
libungif-4.1.0\CYGWIN-PATCHES directory and an empty
libungif-4.1.0-orig\CYGWIN-PATCHES, and keep the "aclocal &&
libtoolize --force" command in conf(), or
2) Lapo runs "aclocal && libtoolize --force" by hand, and then uses
mkpatch to create a gigantic patch that includes not only
libungif-4.1.0\CYGWIN-PATCHES, but also the libtoolization bits.
"aclocal && libtoolize --force" is removed from conf().
Also, it should probably be "aclocal && libtoolize --force --copy &&
automake --gnu --copy --add-missing --force-missing && autoconf" but
that's just me.
Or maybe moving spkg before conf? Is it too "dirty" to let conf actually
change the dir content?
No, you're just missing the point. Suppose I have a package that DOES
need a few changes to .c files in order to compile. Now, of course, I
don't know what those changes are BEFORE I begin working on the package.
So, I relibtoolize and re-automake etc. I configure. I make -- and it
fails in foo.c. I fix foo.c. I make again, and it fails in bar.h. I
fix bar.h...etc.
Now, I'd like to make the distribution -src package...
mkpatch() creates a patch that contains all of the changes that I have
made -- including the re-autotoolization.
End user can apply the patch -- even without having the autotools -- and
'configure; make' and it should 'just work'. OTOH, the patch is
gigantically huge. So, there's a compromise: I can edit the gigantic
page, removing all of the autotoolization stuff, leaving only my changes
to foo.c, bar.h, and everything that is in CYGIWN-PATCHES/. But that's
hard to automate.
The decision on how to handle this is, of course, a maintainer decision.
I have done all of the following in various packages, because each
package is different:
1) just ship the gigantic patch
It's automatic, I don't have to worry about it; the end users don't need
the autotools. The buildscript doesn't call aclocal or any other
autotools. But the patch is big.
2) IF and ONLY IF there are no changes to "real" files (foo.c, bar.h,
confiugre.in) -- the only changes are in CYGWIN-PATCHES/ and
re-autotooliation -- then I can "fake" the patch. In mkpatch:
mkdir -p ${topdir}/foo-VER-orig/CYGWIN-PATCHES
cd ${topdir}
diff -urN foo-VER/CYGWIN-PATCHES foo-VER-orig/CYGWIN-PATCHES > patch
Thus, I can be sure that 'patch' contains only the changes in CYGWIN-PATCHES
and none of the autotoolization. The buildscript calls the autotools, the
end user must have the autotools installed. The patch is small.
Downside: if I ever need to modify a "real" file (foo.c, bar.h) then I
must change the build procedure, which is a PITA.
3) Suppose I need to change some "source" files to get the -deve-
autotools to work properly. This is the most difficult option. I can
create a "pre-autotoolization" patch, which includes my changes to
foo.c, configure.in, Makefile.am, etc. I generate that patch by hand,
*before*running the autotools. 'mkpatch()' becomes
cp <patchfile> ${sinst}/
cp <orig taball> ${sinst}/
cp <buildscript> ${sinst}/
echo "I didn't recreate the patch; any changes you made"
echo "to the sources will be lost"
The buildscript calls the autotools. The end user must have them
installed. The patch is small -- but if it ever needs changing, I must
recreate it manually.
Package with spkg moved just before "conf" and after "prep" (it seemed a
bit overkill to call it -3 for just this small change):
http://www.lapo.it/tmp/libungif-4.1.0-2.tar.bz2
http://www.lapo.it/tmp/libungif-4.1.0-2-src.tar.bz2
This is basically version #3 -- instead of simply copying the patch,
you're recreating it: but you are guaranteed that the "new" patch will
be identical to the old one, since "spkg" is called immediately after
"prep".
--Chuck