Comment 15 for bug 13458

Rob Browning <email address hidden> writes:

> Jérôme Marant <email address hidden> 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