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.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
