* De: John Baldwin <[EMAIL PROTECTED]> [ Data: 2003-01-29 ]
[ Subjecte: Re: Patch to teach config(8) about "platforms". ]
>
> On 29-Jan-2003 Benno Rice wrote:
> > On Wed, 2003-01-29 at 18:46, Marcel Moolenaar wrote:
> >> On Wed, Jan 29, 2003 at 05:32:51PM +1100, Benno Rice wrote:
> >> > >
> >> > > Agreed. There's an advantage there, but see also my reply to
> >> > > Juli about the use of "machine" to mean MACHINE_ARCH and the
> >> > > use of "platform" to mean MACHINE. This I don't find appealing.
> >> >
> >> > I can see your point here, but if needed I'd rather see them renamed to
> >> > MACHINE (which maps to the current MACHINE_ARCH) and PLATFORM as MACHINE
> >> > and MACHINE_ARCH are confusingly similar.
> >>
> >> I'm not sure I understand you. I don't mind the capitalization,
> >> just that we have MACHINE_ARCH and MACHINE defined on the hand
> >> and "machine" and "platform" on the other. If you would ask a
> >> person how they should be related, I can imagine that the
> >> logical should would be to relate "machine" to MACHINE and
> >> "platform" to MACHINE_ARCH. Which is opposite to what Juli
> >> proposed. That's the unappealing part. Not a biggy, but
> >> something that's better avoided now than fixed later.
> >
> > In that case I'm mostly in agreement. Avoiding confusion is a Good
> > Thing(tm).
>
> Just be consistent please. Ignore the implementation and choose one
> of these two paths:
>
> 1) Use MACHINE and MACHINE_ARCH with MACHINE_ARCH being the architecture
> and MACHINE being the platform and use the 'machine' keyword for
> MACHINE with MACHINE_ARCH either explicit (in which case 'machine'
> defaults to 'arch' just like MACHINE defaults to MACHINE_ARCH) or
> implicit from the config file location.
>
> 2) Use PLATFORM and MACHINE with matching config keywords and if
> platform is not specified it defaults to MACHINE.
>
> I don't really care which, but please just pick one and be fully
> consistent. If you go with 1), I suggest an alternative header
> file layout where you have an /usr/include/arch and the machine/
> headers (which are platform-specific) include the arch/ headers
> for common things. I think both ways can work, but please do
> not change the meaning of one set w/o changing the other.
If we change the meaning of <machine>, IMO the requirement to include
up to *every* exported header with a stub is ugly. NetBSD does this.
What if we install them as they're named. "arch" for the multi-arch
systems, "platform" too... And symlink "machine" to arch for backwards
compatability? I have to think that a complete move to a new pair of
words would be GREAT, but we'd want to maintain some (faked) historic
mistakes :) Unless you think that the platform headers should be the
consumers, but of course, then you'd want to invert how the build,
etc., are in what I'm suggesting, or? I mean, a lot of this is out
of wanting the master port to drive, with the meta-data in the back,
reading off the map, as it were.
Aside from that, a pair of "arch" and "platform" would be good, and
have them be mutually exclusive with "machine" where "machine" is for
the "traditional" 1:1 ports.
And retains the old behaviour, modulo any possible new stuff wrt config
file location that "arch" would give us flexibility on.
Thanx,
juli.
--
Juli Mallett <[EMAIL PROTECTED]>
AIM: BSDFlata -- IRC: juli on EFnet
OpenDarwin, Mono, FreeBSD Developer
ircd-hybrid Developer, EFnet addict
FreeBSD on MIPS-Anything on FreeBSD
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
