waf -v clutter

[Fred Wright]

On Sat, 25 Nov 2017, Eric S. Raymond via devel wrote:

> Hal Murray <hmurray at megapathdsl.net>:
> > devel at ntpsec.org said:
> > > waf doesn't know that config.h exists; this is its way to pass configuration
> > > switches.  The fact that we generate a config.h is really legacy behavior
> > > from autoconf and could be eliminated, but it's low on my priority list.
> >
> > It may be "legacy", but I like it.  It's a handy chunk of documentation.
>
> Yeah, there's something to that.  It's why looking into removing it is near the
> bottom of my priority list asnd might never happen at all.

IMO, a config file is a lot more readable than a bunch of bloated compiler
command lines.  It would be even more so if it included comments. :-)

It would make more sense to reserve command-line defines for cases where a
config file doesn't work, such as needing to use different settings for
different components.  But the one time I tried to do something like that,
the difference leaked over into a place where it didn't belong, suggesting
that the current builders aren't structured properly.  I gave up on doing
that, but if another such case arises, there's probably a lurking time
bomb.

> > How do waf geeks keep track of what they built?  What file do they grep when
> > they are trying to see where a suspicious symbol comes from?
>
> I think that's what waf -v is supposed to be for.  That and eyeballing the
> waf recipe files.

That probably tells you what waf *would* build, which may or may not
agree with what it *did* build. :-)

On Sun, 26 Nov 2017, Eric S. Raymond via devel wrote:

> Hal Murray <hmurray at megapathdsl.net>:
> > > > '-DPYTHONDIR="/usr/local/lib/python2.7/site-packages"',
> > > > '-DPYTHONARCHDIR="/usr/local/lib64/python2.7/site-packages"',
> > > > '-DHAVE_PYEXT=1', '-DHAVE_PYTHON_H=1'
> > > Yeah, that's boilerplate for use by Python extensions written in C.
> >
> > I haven't found any uses in our code.  Should we remove it to reduce clutter,
> > or leave it in case we ever want it?  My vote would be to comment it out and
> > add a comment.
>
> There aren't any uses in our code.  Whether we can remove it is a question.
> Have you identified where it's generated.

PYTHONDIR is the install location of the Python libraries.  I wouldn't
expect the C code to care about it.

PYTHONARCHDIR is intended to be the install location for compiled Python
extensions, but since using it as intended doesn't work on some platforms,
it's currently unused (as documented in a comment).

The other two look like things that code might care about if it were
trying to build differently depending on whether Python extensions are
being built, but it's doubtful that they'd be relevant here.

I suspect that all of that comes about due to failure to distinguish
between options needed by the C code and options used solely by the waf
scripts.

Fred Wright