>
>On Wed, 17 Oct 2001, James Chacon wrote:
>
>: Anyways there are is one major include file that gets pulled in:
>:
>: runetype.h (via rune.h)
>
>: 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.
>
>No.
>
>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.
>
>Hacking runetype.h still assumes that the host is NetBSD, or at least
>4.4BSDish, and only makes cross-compiling more difficult.

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.

Actually runetype.h with these changes on a non-NetBSD system will build
just fine. Just include inttypes.h (standard include) and typedef the __uint*
ones needed to uint* equivilants. Or, if you're worried about native namespace
pollution #define __uint* to the uint* versions just for the runetype.h file
scope.

Currently *nothing* in the tools area meets your definition for cross 
compiling. Everything includes netbsd specific include files, netbsd defines,
etc. I've looked at what that would take to make work on say Solaris and it's
not terribly easy because there's a good chunk of libc/libutil that would need
to be brought in as a compat libary also. 

How would you handle something like mtree which includes all sorts of support
for the file flags? Those aren't even on non-netbsd systems so either you
ifdef out the sections of code using them or you design a completely trimmed
down mtree which only uses posix routines. Then you have to keep that somewhat
feature synced with the native one since both use the same baseline definitions
file to build/check systems. Again...maintaince nightmares abound.

>
>: Finally, the really ugly part...When you create a new locale the invalid rune
>: gets set to the INVALID_RUNE macro as the default. This macro though is just a
>: reference to _CurrentLocale which of course isn't a symbol present in anything
>: except -current. (Why the invalid rune for a new locale should default to
>: different values depending on ones current locale while using mklocale is
>: beyond me, but I'm not going there...)
>:
>: The choices are 2:
>:
>: 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, for the purposes of mklocale (in the separate,
>duplicated header file described above).  It should be a constant, rather
>than depend on some user setting, when generating a static file at build
>time.

Which is exactly the opposite of how it works "natively". Thats why I don't 
like it as much. Hard coding it not only depends on the current listed value
in libc (which could change possibly) and is different from how the native
one operates.

Also, in order to deal with this you then need to ifdef yacc.y with something
like HOST_TOOLCHAIN to signify it's being built as the src/tools version.

James