variant or platform

Anders F Björklund afb at macports.org
Sun Jul 15 14:53:11 PDT 2007


Ryan Schmidt wrote:

>> Seems like all the current ports with "x86" or "intel" as the arch are
>> either wrong or typos, though... "darwin x86" should be "darwin i386",
>
> I still say that this needs to be examined and evaluated individually 
> for each port. If nobody's complaining about these ports, then maybe 
> whatever's being done in the darwin x86 platform selector isn't 
> necessary for Intel Macs at all, and might in fact be harmful.

It's just 7 ports, but so far it all looks like they should be changed.

> For example, mpfr has a section "platform darwin x86", but it also has 
> an identical section "platform darwin i386", so the port maintainer, 
> Vincent, should be asked why this is duplicated. I'm Cc'ing him on 
> this email.

I have no idea what kind of Darwin system would return "x86" in uname.
The list at http://wiki.tcl.tk/1649 only mentions "i386" and "i386"...

> And xgalaga has a section "platform darwin x86" which should clearly 
> be "platform darwin i386", and I've changed that now, but the port 
> doesn't build on Intel Macs anyway because it uses (and seems maybe to 
> require) gcc 3.3.

See other email... There is no such i386 gcc-3.3 for Mac OS X 10.4 ?

>> and the one (1) port with "darwin intel" is just plain wrong IMHO.
>
> Ah -- "darwin intel" -- that's why I didn't find it before. Got it 
> now: it's libdnsres. I'm Cc'ing the maintainer, Mark, since he should 
> have a say in this, but I agree, this should be "platform darwin 
> i386". I think he should also remove the unnecessary CFLAGS and 
> LDFLAGS definitions.

Actually it should be "platform darwin 8 i386", but most likely it
should be updating the config.sub and config.guess or so instead ?

>> They should most likely be *standardized* to be "powerpc" or "i386",
>> even though the aliases "ppc" and "x86" are theoretically valid too
>> (for example Darwin 6-7 was i386, Darwin 8-9 are i686, both: "x86")
>
> I don't know what you mean by all of this.

The triplets are:
i386-apple-darwin6
i386-apple-darwin7
i686-apple-darwin8
i686-apple-darwin9

Other operating systems, like Fedora, went through similar changes as 
well.
(whether arch actually returns i386 or i686 depends on some other 
factors)

> I'm on darwin 8 now, and uname returns i386, and "platform x86" 
> sections definitely do not get executed by MacPorts on an Intel Mac 
> currently. If you're suggesting that MacPorts base could be changed so 
> that x86 would also work on Intel Macs, then I again reiterate that I 
> believe x86 is being used in several ports right now in an attempt to 
> target non-Macs. If such a change were made to base, those ports would 
> start failing on Intel Macs.

I meant that i386/i686/x86 are all the same thing, and "i386" is the 
name.

Optimizations for certain processors are done elsewhere anyway, here it
is just talking about the generic architecture - Intel x86 or PowerPC ?

>> It's easy to tweak port.tcl to return "i386" for any "x86" or "i686"
>> machines from tcl_platform, just as it is currently returns "powerpc"
>> for the hopelessly silly `uname -m` return value of "Power 
>> Macintosh"...
>
> It might have been clearer if we had tweaked "i386", "i686", and "x86" 
> to be just "intel", but I'm not sure if we want to go to all the 
> trouble to do that now.

I prefer the shorter x86 and ppc myself, but it doesn't matter much.

The current arch names of "i386" and "powerpc" works just as well,
but if you want to introduce the extra alias "intel" for i386 then do...

>> The suggested "port platform" info command could help people determine
>> what values to put into their platform variants, but for the current
>> common target it's probably enough to make a list of available ones ?
>
> I'm not sure what you mean here? What suggested "port platform" info 
> command?

I formalized the discussion we had earlier into a Trac ticket, #12302

Basically it returns something that would work if put as platform {}

--anders




More information about the macports-dev mailing list