>
>On Wed, 17 Oct 2001, James Chacon wrote:
>
>: >: So what I'm proposing is a new define HOST_TOOLCHAIN that is used to null out
>: >: sections like this (and accordingly have the tools/Makefile's set it within
>: >: CPPFLAGS for all builds). Doing this was relatively simple on runetype.h.
>
>: >The include file needs to be *duplicated* (with appropriately bit-sized
>: >types in the structs) and put in with the mklocale sources so that the
>: >entire mklocale program can be used independently on a non-NetBSD host.
>
>: That introduces a maintaince nightmare. The whole point of reachovers in
>: the current system is to avoid duplicating over and over the same code when
>: it can be used in different places fairly easily like this.
>
>Reachovers are fine, and reachovers are in fact used by src/tools.  However,
>reachovers are used for the sources of programs -- we cannot pull in a
>header file from a library that will only be built for the target system,
>even if it's #ifdef'd all over.
>
>When talking about cross-compiling, host and target tools should ideally be
>considered to be entirely separate entities, particularly in cases where
>binary output files are created.  A host tool should assume that the host
>system has unknown sized "int" and "long" and signedness of "char", and
>unknown endianness.  The ABI should be as explicitly defined as possible in
>the host tool, so no host compiler dependencies will trigger the Wrong Thing
>at build time.

Uhh...this is exactly why one uses int32_t, etc from inttypes.h when porting
anymore. Those are defined portable types (and while runetype.h uses our
internal definitions for them via the __uint* ones from int_types.g it's the
same idea).

The binary file is already platform independent. It writes everything out
with htonl and uses explict width fields when it does it. 


>
>: Currently *nothing* in the tools area meets your definition for cross
>: compiling. Everything includes netbsd specific include files, netbsd defines,
>: etc.
>
>Yes, this is one of the items I've mentioned and am working on now.  At the
>moment, in fact, much of the tools and system builds for me on a Cygwin(!)
>host.  I'm committing these changes as they are stabilized.

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.

At this point no snapshots have been possible with x86 for over a month now...

>
>: How would you handle something like mtree which includes all sorts of support
>: for the file flags?
>
>There is a separate project being worked on by another person right now to
>permit holding back permissions and flags at build time, so you could build
>the system as an unprivileged user, and have the permissions added
>on-the-fly to the resultant tarballs.  As well as a project to make ffs
>filesystems for install media on a non-NetBSD host.

I know about this..It still uses mtree to a degree I beleive. 

Luke?


>In summary:  we are currently in the process of making the build tools run
>on non-NetBSD hosts.  Since mklocale doesn't even compile on 1.5.x, it has
>not been moved into src/tools yet even as a half-done effort.  Because of
>how interwoven mklocale is with libc's rune header files, until it is
>separated and made to cross-compile properly, mklocale should remain
>disabled by default.

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.

I agree the current changes aren't the prettiest style wise. I said that up
front. When a better solution exists, put it in place, but a solution in hand
today beats wins out over "it'll be fixed at some point"..As I said above it's
been over a month so far. How long should one expect snapshot builds to remain
broken if we take your line? 1 more month, 2, 6?

>
>: >: Just set this value (via a netbsd version check) to -3 (which is what it
>: >: defaults to in the end libc code)
>: >
>: >This is the correct choice,
>
>: Which is exactly the opposite of how it works "natively".
>
>The "native" behavior should be changed as well.  Depending on any user's
>external settings for building a static file is wrong.  INVALID_RUNE must be
>a constant when building a rune table.

I agree here. That's fairly easy to fix for the mklocale case but 
INVALID_RUNE itself needs to stay since other code uses it to get the current
invalid rune.

James