Quoting Rob Browning <[EMAIL PROTECTED]>: > By "voodoo magic" do you mean the old approach, the possible md5 > approach, or both?
The combination of both. > If you mean the old approach, then I obviously don't see it to be as > cut and dry as you do. To be fair, the only reason the current code > broke is because the relative timestamps for files in the debian diff > are unpredictable, and I didn't think about that. Of course, that > means that *any* files mentioned in the debian patch are potentially > trouble as far as make is concerned. Without this problem, it would > have been quite correct to have autofiles.diff depend on the files > that may influence its contents (i.e. the *.dpatch files). > > Of course if you just mean that the .md5 approach would be "voodoo > magic", then I'll agree that it's not completely straightforward. > Though to the extent I've thought it through so far, I haven't come up > with any problems. 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? > In any case, even if we go with the "only update when requested" > dpatch-edit-patch approach that I think you're advocating, I'd still > want a target for it so we can just invoke that when needed, > i.e. something (only very roughly) like this: > > update-autofiles-diff: > # rm aclocal.m4 so it doesn't confuse newer autoconfs, but touch it > # so ./Makefile won't be upset if it's not recreated (b/c not > needed). > (dpatch-edit-patch ... autofiles.dpatch > && cd DPATCHDIR \ > && rm -f aclocal.m4 \ > && touch aclocal.m4 \ > && aclocal \ > && autoconf > && exit) > > (...which is really not that much different than what we're already > doing, but I'll agree that handling everything with dpatch would be a > bit cleaner, and if it works right, then I'm fine with that.) It would be kind of better, yes. > So it seems like the *only* thing we're in potential disagreement > about is whether we should automatically invoke this target *iff* > there's a solid way to automatically determine when doing so would be > appropriate. I think so. > > 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 > > It's not only not worth the effort, but it should never have happened > under normal circumstances. As I mentioned, the only reason it did in > this case was because I didn't consider the problem presented by the > timestamps of files in the debian diff and so came up with a broken > solution. I almost all cases, changes to 'configure.in' only change 'configure'. In the remaining cases, changes only happen in the toplevel of the tree. I don't think it is unreasonnable to avoid duplicating the whole tree, isn't it? > The way things were intended to work, the autofiles.diff should only > have been re-built if you changed a relevant file (i.e. *.dpatch), or > if you manually requested a rebuild during "prepare-release". I understood that. -- Jérôme Marant
