That [improving the build scripts] 's completely useless for the user.

Sure, stopping the build process at the first error (to prevent incomplete builds going unnoticed from the user, in the middle of the pile of terminal output created by the build process, and creating trouble later) is completely useless for the user.
So is automatic handling (application, protection against reapplication) of the TIGCC patch to GCC and binutils.
And so is the support for creating a SFX archive ready for use on the same OS flavour.
Yeah, sure

And I don't see those changes as being needed or useful

Such a broad generalization would mean that in your opinion, easing the process of making a release (by adding cross-compilation support) is unneeded or useless ?
That line could also mean that you're dismissing the GCC4TI patches without having sufficiently of a clue...


Kevin, everybody already knows that you don't like the idea of GCC4TI (which wouldn't exist in the first place if you were not such a roadblock to advancing a number of areas of the state of the art of a TI-68k development environment), the GCC4TI contributors (especially me), and the fact that people are using GCC4TI instead of TIGCC. You don't need to emphasize about that on each occasion, and you certainly don't need to blurt out stupidities...

multiple occurrences of "<FlashOS-related code> has not been touched for ... months in the GCC4TI SVN"multiple occurrences of "<FlashOS-related code> is incomplete"

As I wrote:

So far, in GCC4TI, we have spent more time working on:
[...]* features which are, er, used by a higher number of developers than the Flash OS support is.

It means what it reads
A faster linker only matters a lot to OS programmers; it would not be that much of a life-changer for programmers of 32-64 KB programs, which have always lived with 2-5 seconds, depending on their hardware, in the linking stage.