There is such a variable. In the .conf file you specify:
os_target_platform darwin.iPhoneOS.iphone
os_target_platform darwin.iPhoneSimulator.iphone
os_target_platform darwin.MacOSX.pc
along with
os_target_version 4.2
os_target_version 10.6
There are variables that allow you access this information from a port so you
can customize the port down to the target device if that is useful. The design
is such that one has multiple installs of darwin ports (/opt, /iopt, /isopt) in
parallel with each set up in the .conf file to target a specific platform.
I have assumed that the cross-compiling is for an apple platform.
On Feb 3, 2011, at 11:17 AM, James Berry wrote:
>
> On Feb 3, 2011, at 11:05 AM, Toby Peterson wrote:
>
>> On Feb 2, 2011, at 5:49 PM, James Gregurich wrote:
>>
>>> I"m not sure what to do about this one. The expat port does not use
>>> muniversal to do a universal build. The configure script fails when it
>>> attempts to invoke the preprocessor. Is the correct answer to switch the
>>> port to muniversal or is there another flaw for which I should be looking?
>>> I suppose this is happening because I modified the system to put the arch
>>> flags in CPPFLAGS. However, if you don't supply an arch flag of some kind
>>> when building ppc on i386, it seems that should be incorrect behavior even
>>> if it happens to work. It definitely doesn't work without the -arch flag
>>> when building armv6 on x86_64. Can I get some guidance on what this system
>>> SHOULD be doing?
>>
>> configure scripts simply aren't good at cross-compiling. A typical approach
>> is to run the configure script and just correct the results after the fact.
>> A few of my ports do this by running ed scripts that replace definitions
>> with appropriate #ifdef'd values.
>
> I haven't looked in detail at the work you did on MacPorts to try to allow
> cross compiling to iOS, James, but my impression is that it's kind of a hack
> that might work in some cases but probably can't be made to work reliably or
> consistently across ports. I suspect that a better solution is to come up
> with a consistent variant name ('ios' or something) that could be implemented
> per-port as needed, and with appropriate tweaks for each particular port.
> There might be some scaffolding or support that the generic macports
> infrastructure could supply (paths to to the iOS SDKs or compilers, for
> instance, perhaps) but in general I think you'll find each port will need to
> be individually addressed.
>
> James
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
