J�r�me Marant <[EMAIL PROTECTED]> writes: > What I don't understand is why you think that modifying configure.in > and regenerating configure cannot be considered as part of a > regular dpatch. Or maybe am I missing something? > > As an example, the amd64 port needs configure.in to be changed. I > can the see the following scenario: > - run dpatch-edit-patch > - apply changes > - run autoconf: this changes "configure" > - exit from dpatch-edit-patch > > Why wouldn't this work? > > Why is it better to gather all changes to the configure script in > a single separate dpatch rather than spreading all changes along > with the patch it belongs to?
Because IMO modifications to configure.in (and any other autotools related files, like Makefile.in for automake enabled packages, for example) should be made in the .dpatch relevant to the overall change in question. For example, the mailspool patch required changes to a number of files in the source tree *and* to configure.in. I think these configure.in changes should go in mailspool.dpatch, since that's why they're there. The changes in autofiles.diff are only supposed to be the result of "whatever the autools change when run on a fully patched tree", and of course that's not something you can predict without knowing all the modifications that all of the .dpatch files have made to configure.in, to any Makefile.ins (when automake is involved), and to any other files that the currently installed version of the autotools might pay attention to. You could even imagine a foo.dpatch that adds libtool support to a tree that didn't have it. This is going to cause a bunch of new files/dirs to appear in the autofiles.diff, and exactly what appears is going to depend on the version of libtool involved, the libtool macros used in foo.dpatch, etc. Also, as I mentioned before, part of the issue here is that I'd really like to have a solution that's general enough to use with other dpatch using packages, even ones that also use automake, libtool, etc. > I almost all cases, changes to 'configure.in' only change 'configure'. > In the remaining cases, changes only happen in the toplevel of the > tree. As suggested above, I don't think it's safe to presume that changes to configure.in only change configure. Even if that's true now, it might not be true for future versions of autoconf, and it's certainly not true for packages where automake is involved. Actually, it might not even be true in the current emacs21 package since we use aclocal, and I suppose it's possible that aclocal might change what it writes to aclocal.m4 (if anything) from version to version. > I don't think it is unreasonnable to avoid duplicating the whole > tree, isn't it? That's what we do all the time when running dpatch-edit-patch, so I'm not sure why it would be a problem when we're trying to capture an autofiles.dpatch. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
