24.12.2017, Fred Wright via devel:
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 m
On Sat, 23 Dec 2017, Jason Azze via devel wrote:
> On Sat, Dec 23, 2017 at 5:47 PM, Hal Murray 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
> 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"
That's another symptom of our overall development process leaving cruft
around.
That stuff was moved to $build/main/pylib/ quite a whil
On Sat, Dec 23, 2017 at 5:47 PM, Hal Murray 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
> So . . . I just kept running ./waf install, and I think it just cycles
> through these three modes:
> 1) installs ntpq 0.9.7
> 2) Python error 3)
> installs ntpq 1.0.1+183
> I ran a ./waf distclean before my configure, build, install steps. I will
> try from a fresh clone.
> Before I open a Gi
While freshening my NTPsec install to test the ntpq command history
bug, I accidentally ran ./waf install twice in a row because I thought
I had forgotten to run it at all. I thought I had forgotten because
ntpq -V still showed my old version 0.9.7+68.
On the second run, (which at the moment I tho
