svn commit: r359685 - in head: . etc lib/libc/gen share/mk share/termcap usr.bin/login usr.bin/vgrind usr.sbin/services_mkdb

[Ian Lepore]

On Thu, 2020-04-09 at 16:16 -0700, Rodney W. Grimes wrote:
> > Well, how many FreeBSD builds have you run in the last year, Rodney,
> > personally to care about 0.1s slowdown that it might have caused? We've run
> > at least a 1,000 here, probably 3x more.
> 
> That is a non technical personal attack.
> 
> > So yes, the cost is there, the
> > cost is well understood and found negligible versus the benefit of having a
> > slightly more extensible build system that is slightly easier to understand
> > and integrate into bigger projects.
> 
> I do not see how moving 5 values adds any extensibility or any ease of use,
> or intergratability.  It added an ease of editing the values to one file,
> values that *should not be edited inplace*.
> 
> If these values need overridden it should always be done on the make command
> line, especially by projects external to FreeBSD.  Your "extensible build system"
> is reaching into internal project build infustructure in a non-supportable way
> if it requires this types of change.
> 

You did not look at the changes carefully enough.  This doesn't just
gather some values into one place, it replaces instances of hard-coded
tool names with variables.  To do so, those variables need to be
defined somewhere.  A new src.tools.mk is a good sensible place for
that.  Now that you have them all in once place, it doesn't make sense
to still have duplicate definitions in other places, everything should
refer to the one new source.

You have focused in on that last sentence and started complaining about
it as if it were the entire change.  It's just a minor cleanup which is
the natural thing to do given the rest of the change.  And the rest of
the change is useful in exactly the ways Maxim is saying (I say that as
someone who also maintains a large proprietary source base that uses
the freebsd build infrastructure).

-- Ian