emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VCSWITNESS = fail ** 2


From: Eric S. Raymond
Subject: Re: VCSWITNESS = fail ** 2
Date: Sun, 12 Jan 2014 13:45:23 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

Eli Zaretskii <address@hidden>:
> Actually, I take that back: the original code should work, and works
> for me.
> 
> So let's please step back one notch: can you please tell what exactly
> is wrong with the way vcswitness is computed and passed to the
> sub-Make?

What I know is this: 

I was trying to modify that code to DTRT in both a Bazaar and .git repo, 
using .git/HEAD as a witness in the latter case.  The way my modification 
failed caused me to suspect that the original code hadn't been working.

So I reverted to the trunk version and instrumented, by inserting an
echo before the generated make command.  Lo and behold, vcswitness was
empty.

I looked again.  Had I doubled $ properly for the make context?  I had;
vcswitness was really empty.  (But I was already pretty sure of that; if
doubling $$ had been incorrect it would have expanded as somebody's 
process number.)

I looked at those three lines again, saw the two different paths, and
made a deduction about the failure source that it now appears was 
incorrect.

But I've been around the track a few times, and I know that because 
of (a) conflicting Makefile and shell expansion rules  and (b) the
hair associated with nested Makefiles, this sort of code is notoriously
easy to misread (as Eli was later reminded himself).

So I posted to the list and waited for somebody to point out the flaw
in my reasoning.  Nobody did. Meanwhile, in my own test builds
vcswitness continued to be spuriously empty.

The rest you all know.  Eli took his own comic pratfall, momentarily
breaking the build. And he's been around the track a few times himself.

At present, I have no explanation for the observed differences in
behavior more predictive than "phase of the moon".

Those three lines are, by demonstration, so prone to be misread that they 
tripped up Eli and me in two different ways and I still have no theory
to account for why they were different.

That says "maintainence nightmare - should be scrapped and replaced"
to me.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]