>> Only that the version and EPOCH stuff are currently tangled up with
>> configure and I think we want to disconnect that.
> I don't see how that can be done.
One way is to run a script that makes a header file with version and EPOCH
info. I'm not enough of a waf wizard to be able to do it wi
Yo Hal!
On Tue, 23 May 2017 13:56:07 -0700
Hal Murray wrote:
> >> configure sets up NTPSEC_VERSION_STRING
> >> ntptime is the only useage.
> > Seems like a different issue than detecting an old or unusable
> > configure. Do you propose a tie-in?
>
> Only that the version and EPOCH stuff ar
There may be some confusion between comments about what exists and what I'd
like.
> Yes. People forgetting to run configure is a persistent problem.
Eric: An item for your list.
I don't have any good suggestions for how to fix that. I think it could also
happen if a tarball was extracted on
Yo Hal!
On Mon, 22 May 2017 23:26:05 -0700
Hal Murray via devel wrote:
> I think the tangle mentioned at Issue #313 needs wider discussion.
> ntpsec | build version not updated after git pull (#313)
> https://gitlab.com/NTPsec/ntpsec/issues/313
Yes. People forgetting to run configure is a
I think the tangle mentioned at Issue #313 needs wider discussion.
ntpsec | build version not updated after git pull (#313)
https://gitlab.com/NTPsec/ntpsec/issues/313
A while ago, we changed things to not use __DATE__. Maybe we didn't get that
right. Maybe the default should be to use __D