svn commit: r365643 - head/bin/cp

[Kyle Evans]

On Tue, Sep 22, 2020, 17:02 Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Tue, Sep 22, 2020 at 3:55 PM Kyle Evans <kevans at freebsd.org> wrote:
>
>> On Tue, Sep 22, 2020 at 4:53 PM Ian Lepore <ian at freebsd.org> wrote:
>> >
>> > On Tue, 2020-09-22 at 15:50 -0600, Warner Losh wrote:
>> > > I think it's a great leap sideways, but I've done cp /dev/null foo to
>> > > clear
>> > > it out for 35 years now... It's why it feels like a workaround.
>> > >
>> > > Though it is a legit optimization, no matter the feelings. As for
>> > > clearer,
>> > > I'm less sure since then I have to remember what the : operator does.
>> > >
>> > > Warner
>> > >
>> >
>> > For me, :> is idiomatic (but ugly).
>> >
>> > On the other hand, the cp /dev/null had a nice dogfooding aspect to
>> > it... when we broke cp by accident, its use in the build system was the
>> > first alarm to go off.
>> >
>> > --Ian
>> >
>>
>> To be honest, this is a case that really should be covered by
>> regression tests somewhere.
>>
>
> It should (but isn't yet).
>
> Ian is right for old-school FreeBSD thinking. In that thinking the build
> system should use an eclectic mix of tools to act as a fire-wall against
> accidental breakage.
>
> Complete, effective, test suites give much better coverage... if they are
> run...
>
> So until we run tests frequently, with loud regression squawking that's as
> effective as build breakage, I tend to fall in the 'all of the above' camp
> until that's in place... :)
>
> Warner
>
> P.S. though not, if I suppose, if it means that we're slowing down the
> regression coverage uptake...
>

--

The test build was fine, please confirm if I can commit it or if someone
else would like to write the UPDATING notice or start bootstrapping cp on
systems that were affected. I'm not comfortable with not taking any path at
all here, but this is a lot of friction for a small mechanical change to
ease the pain.

Thanks,

Kyle Evans

>