waf: --disable-attic

[Fred Wright]

On Tue, 15 Feb 2022, Hal Murray via devel wrote:
>
> Matthew.Selsky at twosigma.com said:
>> Are we worried about the speed of the build, lack of build support on
>> particular platforms, or something else?
>
> I'm not particularly concerned about the speed of a build.  As far as I know,
> nobody has complained about build times or suggested not building attic to
> make builds go faster.
>
> The reason it came up is because our latest release doesn't build with OpenSSL
> 3.0.  The main code in ntpd builds but something in attic breaks.

Indeed.  Right now, if anything in attic fails to build, then the entire 
build is broken, even though nothing in attic is to be installed.  IMO, 
any item which is neither installed by 'install', nor needed to build an 
item installed by 'install', shouldn't be included in the default build.

The OpenSSL issue is compounded by the fact that specifying an alternate 
version of OpenSSL (or any other third-party library, for that matter) 
can't be done straightforwardly because the build fails to honor the paths 
obtained from pkg-config.  There's a special hack that's only for Linux, 
and only for OpenSSL in one particular alternate location, that wouldn't 
be necessary if pkg-config were respected.  The problem is that 
ctx.env.INCLUDES and ctx.env.LIBPATH weren't designed to be used for 
external libraries.

> The feature is simple to implement: 2 or 3 lines in each of 3 places, so it
> seemed like it might be handy next time somebody runs into a problem like this.

IMO, a separate waf target would be a better way, but teaching waf about 
that might be more complicated than adding the option.

> If the default is on, we may get a heads-up that something might need
> attention.  If the default is off, we don't have to answer questions when
> people encounter problems in attic.  The conditions are rare enough that I
> don't think it matters.

I don't think anything in attic is really intended for the former purpose, 
except by accident, but if that's really a concern, the pre-release 
checklist could include testing the attic build.  Gratuitous build 
breakage isn't a plus.

> Does anybody other than me look at the stuff in attic?  Or run them?

I sometimes run them, and have tripped over the build issues multiple 
times.  I maintain some patches to make ntpsec work on older macOS 
versions, which includes (among other things) a fallback for 
clock_gettime().  This is in ntp_machine.h, so every time an attic program 
is added that uses clock_gettime() without including ntp_machine.h, the 
entire build fails until I fix that program (five so far).

Fred Wright