Also, I don't know whether assuming the cctools or the clang from macports is a good assumption to make. I can install gcc from macports and build with that. Or icc. Thinking about this some more... (1) if we are in a PPC system, we have two options: 10.3 or 10.4. The 10.3 is what we have been "always" using; 10.4 is the first with Intel support. (*). The 10.4 is also what the macports guys recommended for PPC. So I would say 10.4 here. (2) if we are in an x86_64/ia-32, we have an obvious max (what the SDK supports), and an obvious min (what the OS itself is). I'm coming to the opinion of using the OS level (as opposed to Jens' patch): it looks less odd (as pointed out by Craig), and if a SDK works at the OS level, it should be able to produce binaries that work at the OS level, no? (3) fallback default, if nothing else works, on x86_64/ia-32 is - at this moment - 10.7 (macports guys) (4) we have to consider two kinds of users, at least: (4a) those building for this and later (as far as Apple's bincompat stretches to the future) -- bleadperl smokers here (4b) those building for some earlier target level (again, Apple's bincompat strechiness, to the past) -- system integrators here Theoretically, one could also build for some future level, if the SDK allows, but I think this use is rather far-fetched to bother considering. For the (4b) we would need to have a way to enforce building for an older level. I would suggest the env $MACOSX_DEPLOYMENT_LEVEL. (*) According to Wikipedia: PPC 10.0 until 10.5.8; ia-32 10.4.4 until now; x86_64 10.4.7 until now (**) I use it here to mean either x86_64 or ia-32 --- via perlbug: queue: perl5 status: open https://rt.perl.org/Ticket/Display.html?id=126360Thread Previous | Thread Next