os.major etc. on Linux

[René J.V. Bertin]

On Friday May 13 2016 15:21:53 Joshua Root wrote:

>>> Side-ways related: why is os_arch reset to i386 from x86_64 on line 636? >From what I've seen that causes packages to be labelled and registered as i386 (i.e. 32bit) when built on 64bit linux.
>>
>> In MacPorts, os_arch is i386 on all Intel Macs (32-bit and 64-bit), and ppc on all PowerPC Macs (32-bit and 64-bit). Changing that now would break all ports that rely on the existing long-standing behavior.

I was just asking why, apparently that's a historic choice that was made when 64-bit Intel Macs weren't on the horizon yet?
Either way, I am NOT proposing to change it for the Darwin platform. If it's OK to consider a fix for the OS version issue it might possibly also be OK to consider handling os_arch (os.arch) differently on that platform, i.e.

{{{
    if {${os_platform} eq "linux"} {
        if {$os_arch eq {i586} || $os_arch eq {i686}} {set os_arch "i386"}
    } else {
        if {$os_arch eq "i586" || $os_arch eq "i686" || $os_arch eq "x86_64"} {set os_arch "i386"}
    }
}}}

>This corresponds to `uname -p` BTW.

I don't have access to my Mac right now, but on Linux/64-bit that command says x86_64 . Is that what $tcl_platform(machine) does/contains?

If memory serves me well, setting os_arch to i386 on 64-bit Linux led to frequent if not continuous requests to install port dependencies (because somewhere they were considered available only as 32-bit) which were then satisfied immediately because the ports were in fact already installed.

I'm curious though, what ports rely on i386 meaning "Intel, 32 or 64 bit" rather than "Intel, 32 bit", directly in their Portfile rather than indirectly through "base"? I find that confusing and it often makes me pause when I see the term appear in the log of a build I know should be for 64-bit (and it feels to me to be as smart as using an undocumented feature ;)).

R.