Rob Browning <[EMAIL PROTECTED]> writes: > Jérôme Marant <[EMAIL PROTECTED]> writes: > >> To my mind, we should avoid to do this automatically from the makefile >> and generate a dpatch manually every we have to regenerate the >> configure script. > > We certainly could generate the patch manually, and that would be > simpler, but it would also leave a lot of room for mistakes, > especially when someone else wants to hack on the package. They won't > know that they (may) need to regenerate the autofiles.diff after they > add a new patch or change an existing one.
I don't agree. It only has to be documented. Let's be frank: I personaly don't like the idea of the voodoo magic which acts in the shadow and breaks unexpectedly some random day. > Whatever we do, we'll still need to make sure the autofiles patch is > the final patch, since any of the other patches might make changes > that affect the autotools behavior. > >> Currently, the only file which is modified when changing configure.in >> is configure, so this should be straightforward. > > True, though there's no guarantee of that. Some newer version of > autoconf or aclocal could create extra files or pay attention to > source tree elements that older versions didn't. That's the reason > for the current approach: > > - apply all the other patches to a temp tree > - run the appropriate autofoo on the temp tree > - diff the temp tree and the original tree I don't agree. If new versions of autoconf and aclocal create new files, those files are automatically added to the dpatch by dpatch-edit-patch so there isn't any chance to see bad surprises. IMO, creating a whole copy of the tree and diffing at build-time is not worth the effort. You have the final word, anyway :P -- Jérôme Marant
