[MacPorts] #41589: mercurial @2.8 build failure on 10.9

[MacPorts]

#41589: mercurial @2.8 build failure on 10.9
-----------------------------+---------------------
  Reporter:  petr.fischer@…  |      Owner:  deric@…
      Type:  defect          |     Status:  closed
  Priority:  Normal          |  Milestone:
 Component:  ports           |    Version:  2.2.1
Resolution:  invalid         |   Keywords:
      Port:  mercurial       |
-----------------------------+---------------------

Comment (by sean@…):

 Replying to [comment:9 william@…]:
 > Replying to [comment:8 ryandesign@…]:
 > > Why would you set `macosx_deployment_target` to any value in MacPorts,
 much less "10.4"?
 >
 > Because It's There™ :)
 >
 > More seriously: you'd set it in order to (exactly as you say) build
 macports packages on 10.9 which are able to work on an older OS version. I
 agree that 10.4 would be unlikely to work! 10.6 should work fine though I
 think (though it remains to be seen, I'm experimenting). That's what the
 MACOSX_DEPLOYMENT_TARGET is ''for'', and it does work pretty well in my
 experience! Macports aside, building software on 10.9 which should run on
 anything 10.6 or later is a pretty standard thing to do, surely.

 Standard for projects that are distributing their own binaries, sure.
 Which is what MacPorts does.

 > > The only reason to change `macosx_deployment_target` is if you plan to
 build software on a newer machine and then be able to run it on an older
 machine, but that's not a use case MacPorts is well-designed for
 >
 > What is the MacPorts variable macosx_deployment_target for, then? If it
 doesn't work, should it not simply be removed? I'm not asking to be
 difficult, just can't see a use case for it except that. (And please don't
 remove it, I'm using it, and I'm clearly not the only one … and it does in
 fact appear to work well for this purpose so far, even if macports wasn't
 well-designed to support it! :)
 >
 > > and in any case trying to build software on 10.9 and then be able to
 run it on 10.4 is not likely to succeed.
 >
 > 10.4 no, I agree, that's unlikely to work, it's really too old and the
 Apple tools don't support it as well I think. It might though (x86
 architecture only, not x86-64, and certainly not ppc or ppc64 since recent
 Xcodes can't target those) … but in any case 10.6 should be fine. That's
 what the MACOSX_DEPLOYMENT_TARGET environment variable (and the -mmacosx-
 version-min compiler flags …) are for, isn't it?

 It seems there's a confusion between MacPorts and the compiler flag. The
 compiler flag is useful and provided by Apple for obvious reasons: a
 (stand-alone) project wants to distribute a binary that works with 10.X
 SDK. Fair enough. The MacPorts variable exists to pass this value down to
 the compiler. Only a handful of ports (~20) even use this variable.

 So, the use case would be that you build a binary on your machine and
 distribute it to others that don't have MacPorts? I guess that'd be useful
 for environments that have a lot of workstations to setup or something
 like that.

 I think the easiest thing to do would be to implement #41783 and make sure
 the environment variable is set for all phases. I honestly can't tell if
 that's happening or not by reading the code in `portutil.tcl`.

 > Incidentally, I think it's possible that the originator of this bug
 /had/ upgraded his machine from 10.8 to 10.9, his “clean install” iin
 comment 4 was only of mercurial, and this problem might appear if macports
 hadn't been upgraded properly after the OS upgrade.

 Yes, I agree.

-- 
Ticket URL: <https://trac.macports.org/ticket/41589#comment:10>
MacPorts <http://www.macports.org/>
Ports system for OS X