Hal Murray :
>
> The default was --enable-debug. A while ago, that was changed to
> --disable-debug.
>
> I think we should reconsider that and/or this whole area.
>
> There are several things all lumped together under --enable-debug and/or
> --enable-debug-gdb
>
> One is a bunch of optional
Yo Hal!
On Fri, 14 Apr 2017 12:35:24 -0700
Hal Murray wrote:
> g...@rellim.com said:
> >> The default was --enable-debug. A while ago, that was changed to
> >> --disable-debug.
> > And then changed back to --enable-debug
>
> When was it changed back? I don't see that.
Covered in the git
g...@rellim.com said:
>> The default was --enable-debug. A while ago, that was changed to
>> --disable-debug.
> And then changed back to --enable-debug
When was it changed back? I don't see that.
Maybe we are having a word mixup. How about this way?
The default was DEBUG enabled. A few week
Yo Hal!
On Fri, 14 Apr 2017 03:27:19 -0700
Hal Murray wrote:
> The default was --enable-debug. A while ago, that was changed to
> --disable-debug.
And then changed back to --enable-debug
Right now --enable-debug enables only things that developers need
or want. It enables things that are sc
On Fri, Apr 14, 2017 at 6:27 PM, Hal Murray wrote:
>
> We should probably measure the size difference and/or run time differences.
> The latter will take something like a busy pool server.
I have one, ntpmon.dcs1.biz , in a very busy pool, IPv6, ntpsec git head,
with gpsd git head. Debian test
The default was --enable-debug. A while ago, that was changed to
--disable-debug.
I think we should reconsider that and/or this whole area.
There are several things all lumped together under --enable-debug and/or
--enable-debug-gdb
One is a bunch of optional compiler checking options - the s
