This is the mail archive of the 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: [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, -- 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,,, 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):

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


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