Re: Deprecating non-functional SHAREDSTRINGS build option and xstr(1)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 24 May 2023 20:00:19 +1000
    From:        Luke Mewburn <luke%mewburn.net@localhost>
    Message-ID:  <ZG3gM0/Hzc3NmSnJ%mewburn.net@localhost>

  | Well, that thread's the epitome of a NetBSD bike shed...
  | A minority arguing to retain a feature (mkstr, xstr) that hasn't worked
  | for 2 decades (at least, never had cross-build support),

I think you should be clear what you're discussing here.   I was one
of that (apparent) "minority" - but I was certainly never opposed to
removing SHAREDSTRINGS support from the build system, I didn't even know
it was supposed to be there.   I can certainly accept that that doesn't
work, and removing it is no issue for me at all.

But that's an entirely different thing than the programs (mkstr and xstr)
being removed.    Further I see nothing in mkstr.c which would in any way
"not work", and cross-build support for it should be no different that
for cat or ls (or any other random program) and as we cross-build almost
everything (except perhaps amd64 usually) I very much doubt that either mkstr
or xstr are failing.

That's quite different that using then as tools in a cross-building 
environment though, I can't see why mkstr would be a problem even there
though, but xstr might be.

So, no objection at all to SHAREDSTRINGS being removed (which I think has
already happened) - but I still see no rational reason (beyond "I don't see
a need for it") to remove the programs from the system.

If "I don't see a need for it" is to be the criteria for what to remove,
then I can easily send a list of all the things I don't see a need to
keep, which I could then remove, but I suspect that there might be plenty
of people who might have some objections to some of my list.

kre