multiple arch flags won't work with -E

[James Gregurich]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110203/e7eb9ce1/attachment-0001.html>