[MacPorts] #64229: python27 +universal fails to build for ppc+ppc64 on 10.5.8

[MacPorts]

#64229: python27 +universal fails to build for ppc+ppc64 on 10.5.8
---------------------------+-------------------------------------
  Reporter:  barracuda156  |      Owner:  (none)
      Type:  defect        |     Status:  closed
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.7.1
Resolution:  duplicate     |   Keywords:  PowerPC, Leopard, ppc64
      Port:  python27      |
---------------------------+-------------------------------------

Comment (by kencu):

 So, MacPorts is supposed to handle this properly, but there are some
 hiccups in MacPorts' logic on this.

 MacPorts knows that cmake is a tool that does not need to be the exact
 architecture being built, because the cmake Portfile tells it so with this
 line:

 https://github.com/macports/macports-
 ports/blob/81fa5fc77bfc3090ac0717eb3d8f6c91a74b095e/devel/cmake/Portfile#L23

 that says:
 {{{
 installs_libs       no
 }}}

 So if you already have cmake installed as ppc, and then you try to install
 something that needs cmake as ppc64 or universal, Macports is SUPPOSED to
 see that line, and use your installed cmake for the build, even though it
 is not universal.

 I find this usually, but does not always, work, for reasons I have no idea
 why not, and sometimes it is necessary to explicitly tell MacPorts in the
 Portfile of a given port that you specifically don't care about the
 architecture of some given other port with a line like this:

 https://github.com/macports/macports-
 ports/blob/81fa5fc77bfc3090ac0717eb3d8f6c91a74b095e/lang/llvm-9.0/Portfile#L56

 which says that you don't care about the architecture of some tool with a
 link like this:
 {{{
 depends_skip_archcheck-append ld64 subversion
 }}}


 So -- if you know that the architecture of cmake does not matter, you can
 just install cmake directly:
 {{{
 sudo port -v install cmake
 }}}

 and then if all is working well, MacPorts will not try to rebuild cmake as
 universal, but if it flubs out for no reason you can understand, you can
 add:
 {{{
 depends_skip_archcheck-append cmake
 }}}
 in the Portfile that seems to be demanding to rebuild cmake as universal,
 and then it should no longer try to do that.


 There is a different scenario that can occur, however.

 Let's say you have no ports installed, and then you try to install some
 port that needs cmake as +universal.

 What happens then is that the {{{+universal}}} part of your request will
 be automatically passed up the chain to all other ports as explicit
 variants, so MacPorts will then specifically see that cmake is not yet
 installed, and helpfully give itself the command to
 {{{
 port install cmake +universal
 }}}

 As far as cmake knows, it can build itself as ppc and ppc64, and so it
 accepts that, and tries to then build all it's deps as ppc and ppc64.

 But then python27 will not build as ppc and ppc64, so the universal build
 of cmake as ppc and ppc64 fails, and the whole system comes to a halt with
 a build error of some kind.

 The solution, which should be to do something like this:
 {{{
 sudo port clean (everything that was trying to build)
 sudo port -v install cmake
 sudo port -v install my_needed_port +universal
 }}}

 which should then just build away and leave cmake alone, is not obvious.

 The exact same error/issue comes up with many many different build tools,
 like ninja and gmake and others -- all of which have at one time or
 another triggered complaints that they won't build universal (see 1000
 tickets) when in point of fact, none of them are really needed as
 universal for the task at hand.

 But MacPorts doesn't know if you really want a universal cmake or ninja,
 or if you are just building something else universal that needs those.

 You can see, with a few minutes thinking, that this is kinda hard to sort
 out for the general case.

 So -- short story -- if you first install your build tools WITHOUT using
 universal, you should be fine for any of them that don't actually need
 universal code in them.

-- 
Ticket URL: <https://trac.macports.org/ticket/64229#comment:5>
MacPorts <https://www.macports.org/>
Ports system for macOS