Subject: Re: mklocale and the new toolchain
To: Todd Vierling <email@example.com>
From: James Chacon <firstname.lastname@example.org>
Date: 10/17/2001 14:53:52
>On Wed, 17 Oct 2001, James Chacon wrote:
>: I'd prefer snapshots to build clean then waiting for cygwin hosted support.
>: I actually doubt you'd find anyone who compiles snapshots on a regular basis
>: to want them to remain broken untl a private pet project (or work related one
>: for that matter) is perfected to the point that it can be checked in to support
>: all of this. Foreigh build support is a great thing (and I have also looked
>: into parts of this), but leaving the tree in a non-buildable state snapshot
>: wise in the meantime is ridiculous.
>mklocale was disabled precisely to *allow* the tree to build properly.
>Enabling it without proper fixes will break the build on platforms that will
>be otherwise completely usable as hosts shortly.
No...disabling the locale builds makes them unavailable on platforms that
previously got them. Thats not a proper build by any stretch. You've now
removed functionality from people's systems because the tool doesn't
build clean? Fix the tool then.
Plus the tree still didn't build properly because all ports have the locale
files referenced in the set lists. Pulling those out into my proposed toolchain
specific ones is a major hack.
>: I disagree. As the diffs show, making this compile on a 1.5.x system is trivial
>: and there's no reason not to do it. Instead telling everyone running -current
>: past early Sept "you no longer get locale's built" is kinda drastic.
>Making this a drastic change was deliberate, so that (hopefully, though my
>mails to itojun have gone unanswered) those interested in the locale code
>would fix it properly.
>This thread is going in circles, and I have to focus on today's issues. Go
>ahead and implement it, but please leave the host build where it is in the
>tree (e.g. don't make a src/tools version of it yet). I'll look at
>splitting the runetype.h file apart later.
I can split it. Thats not the issue so much. I proposed a solution. I didn't
say it was perfect (as a matter of fact I specifically said it was ugly).
If it's going to get argued that it's not the best way to deal with it, fine.
However a proper response would be ideas on a better solution rather than
"leave it all disabled and I'll look at it later"...
Plus making the changes and *not* putting this in tools/mklocale defeats the
entire purpose of this whole exercise.
There's not even a whole lot of reason to split runetype.h apart if the
types are changed to use inttypes.h typedef's and the default invalid rune
is just #define'd. I'll do that and resend it out.