uname -a display BeOS instead of Haiku

[emitrax]

I think it's time to update platforms_types as uname -a prints BePC and BeOS instead of Haiku and i{3,4,5,6}86.

[axeld]

uname now reports the OS as "Haiku" as of hrev26130. Platform (ie. machine) and processor are still wrong, though.

[andreasf]

Doesn't this break automake and friends, or has Ingo already prepared for this? That would be very bad if this bug is just about cosmetic uname output.

[anevilyak]

Well, in the long term we don't really want to be identified as uname BeOS anyways, since for a lot of ports that enables tons of hacks around POSIX problems, etc. that we no longer need, as you well know. Not sure as to the current state of things though with respect to automake and such.

[axeld]

This only affects the output of "uname -o" and "uname -a" - configure scripts should usually use "uname -s" or something else instead.

[emitrax]

As far as I know they use uname -s which outputs already Haiku, but I'd like to hear Ingo about it. Anyway, as Renè said already, Haiku is not BeOS and better fix this sooner than later.

[andreasf]

Sure it should be changed. I was just raising the issue that, first, it should be checked whether any Optional Package may need to be updated before committing lots of (necessary but potentially breaking) changes. If you've checked that it doesn't affect the Development package, then I'm okay with it. I was just missing a statement that this has been thought of.

[bonefish]

Replying to emitrax:

As far as I know they use uname -s which outputs already Haiku, but I'd like to hear Ingo about it.

I haven't seen any tool evaluating "uname -o" so far. Not that I have looked for that particularly, though.

Anyway, if we change BePC this will have consequences. We might want to do that together with dropping __BEOS__.

[emitrax]

Replying to bonefish:

I haven't seen any tool evaluating "uname -o" so far. Not that I have looked for that particularly, though.

Funny thing is that discovered this bug by running the configure of cscope which uses uname -o, anyway that's not the point.

Anyway, if we change BePC this will have consequences. We might want to do that together with dropping __BEOS__.

Ok. Has any plan been made about that? Is it going to be after R1?

[andreasf]

Replying to emitrax:

Has any plan been made about that? Is it going to be after R1?

I think the plan was to drop it asap, to allow proper porting. But it requires someone knowledgeable to fix GCC's headers, they depended on __BEOS__ last time I checked. Not sure if we have a ticket for that.

[scottmc]

Is there something that still needs to be fixed here?

~> uname -s
Haiku
~> uname
Haiku
~> uname -o
Haiku
~> uname -a
Haiku haikubox 1 r29127 Feb  3 2009 09:58:35 BePC Haiku

[emitrax]

I guess the word "Be" should totally be dropped.

[korli]

What should BePC be replaced with ?

[emitrax]

IMHO with the architecture. Either i{3,4,5,6}86, PPC, m68k, arm :-)

[scottmc]

From config.guess:

    BeBox:BeOS:*:*)	# BeOS running on hardware made by Be, PPC only.
	echo powerpc-be-beos
	exit ;;
    BeMac:BeOS:*:*)	# BeOS running on Mac or Mac clone, PPC only.
	echo powerpc-apple-beos
	exit ;;
    BePC:BeOS:*:*)	# BeOS running on Intel PC compatible.
	echo i586-pc-beos
	exit ;;
    BeMac:Haiku:*:*)
	echo powerpc-apple-haiku
	exit ;;
    BePC:Haiku:*:*)
	echo i586-pc-haiku
	exit ;;

So if we were to drop "BePC" it would affect ALL ports that relay on config.guess. Not sure what we've even change it to, i686:Haiku, PPC:Haiku, X64:Haiku?

So a change to uname should have a matching change to our config.guess

[bonefish]

I wouldn't change the "BePC" for x86. This just causes unnecessary inconveniences for porters without any benefit. The "BeMac" could still be changed to "PowerPC". There aren't any ports for PPC ATM, so if the change to config.guess is upstreamed now, it might have found its way into most packages by the time it becomes relevant. For all newer/other architectures (x86_64, m68k,...) adequate machine names should be chosen.

[axeld]

Completely agreed - but this also means we can close this ticket, I guess.