Issues raised by buildprep

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>: 
> To me, buildprep looks like a step backwards.  I'm trying to figure out why.

It looks to me like you have figured out why.  And I don't dismiss
these issues, but I also don't see how to completely solve them
without adding annoying complexity to our build chain and complicating
our lives once we have more end-users.

> I think the real issue is that our whole build and install chain is
> almost an all-or-nothing.  There is a configure option to skip the
> documentation and/or it gets disabled if asciidoc isn't available,
> but there aren't any parallel options to skip building or installing
> ntpviz or ntpq and the other python tools.

It's a fair point.  So let me tell you why I haven't thought about
adding such options.  In brief: every feature switch implies a rash of
trivial bug reports from people who didn't understand it.  I'd much
sooner get rid of the ones we have (I've come near nuking
--enable-crypto several times) than add new ones.

I've made a conscious choice to prioritize reducing config switches
and consequent downstream noise over being nice to people like you who
want to customize for least possible footprint.  What you are actually
arguing with is that choice, which is OK - I'm willing to have that
argument, and maybe move a bit in the other direction, as long as we
all understand what the issues and the downstream costs are.

So my next question to you is: what is the lowest number of optional-feature
groups that would make you happy? Is the only real issue the group of Python
tools?  Because I think I could live with one big feature option for that,
but more would have rapidly diminishing returns in terms of flexibility
gained per complexity cost incurred, and thus make me unhappy.

A related problem is that messing with the waf recipe is unpleasantly
complicated and a nasty time sink. We need a maintainer for that who
isn't me.  Are you perchance volunteeeing? ;-)

> We probably want a dumb, stupid, but small version rather than the
> bloated ntpd.  (It will be interesting to see the size difference,
> especially if we add a few ifdefs to omit things like the statistics
> files.)

>From familiarity with the code I can tell you that that the statfile
support doesn't actually cost much.  The big targets in terms of
reducing binary size and memory footprint while running are

(1) Conditioning out refclocks (which we can already do)

(2) Conditioning out MRUlist support (which we can't do yet, but
wouldn't be difficult - I could probably have that switch done and
tested in 90 minutes).
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>