./waf install is not idempotent?

[Fred Wright]

On Sat, 23 Dec 2017, Jason Azze via devel wrote:
> On Sat, Dec 23, 2017 at 5:47 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
> >
> >> I ran a ./waf distclean before my configure, build, install steps. I will
> >> try from a fresh clone.
> >
> >> Before I open a GitLab issue, is this unexpected behavior?
> >
> > It sure looks unexpected to me.  There shouldn't be anything about 0.9.7
> > left.  (except in history)
> >
> > Try grepping for 0.9.7 and see if you find anything interesting.
>
> A bunch of stuff in the packaging directory under SUSE and RPM, and this:
>
> ./pylib/version.py:VCS_TAG = "NTPsec_0_9_7"
> ./pylib/version.py:VERSION = "0.9.7"
>
> I could not reproduce the weirdness with a fresh clone. So, as I've
> said before, ./waf distclean can't be trusted and ./waf clean can be
> trusted even less. :-)

The trouble with "clean" features in build systems is that they normally
clean what they'd build and/or install with the *current* state of the
code (and in some cases, the current options), but can leave stuff behind
when the code or options change.  You can minimize this by cleaning
between build code updates (and always cleaning with the same options as
you used to build, if they're not sticky).

If you're working in a git repo, then the most effective clean is "git
clean -dxf".  Beware that this nukes *everything* that's untracked or
ignored (other than the .git tree, of course); if you want to "look before
you leap" use "git clean -dxn".

Fred Wright