[MacPorts] #48024: charm-qt5 @1.8.0_20150312: cannot evaluate portfile

MacPorts noreply at macports.org
Thu Jun 11 14:01:44 PDT 2015


#48024: charm-qt5 @1.8.0_20150312: cannot evaluate portfile
------------------------+-------------------------
  Reporter:  larryv@…   |      Owner:  rjvbertin@…
      Type:  defect     |     Status:  new
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:
Resolution:             |   Keywords:
      Port:  charm-qt5  |
------------------------+-------------------------

Comment (by rjvbertin@…):

 Smoothly? Take the qt5-1.0.tcl PortGroup from
 https://github.com/RJVB/macstrop/blob/master/_resources/port1.0/group/qt5-1.0.tcl
 (and rebuild).
 I'll prepare a cleaned copy of that portgroup and upload a diff. Some
 things have been moved around to increase readability (in my eyes), which
 doesn't of course help the legibility of the unified diff.

 When I do a side-by-side diff with the current mainstream one it seems
 clear where that one came from (I'm trying to avoid the pla word) and that
 some ad-hoc pro-forma changes were made without too much consideration for
 their consequences.

 Normally I'd point out that the binary install prefix is different in my
 version, but if so many ports don't build at all it won't be an issue to
 change this from ${prefix}/libexec/qt5-mac to ${prefix}/libexec/qt5 .

 I see some of my earlier observations were wrong (OR the portgroup file
 was updated later, without bumping the $Id), but also that the mainstream
 portgroup takes the approach to install ALL of Qt under ${prefix}/libexec
 .
 In my experience that is NOT a good idea, because even if well-behaved Qt5
 dependents will find the stuff in there, it interferes with how
 ${prefix}/share is conceived. There are undoubtedly good reasons why all
 Linux distributions put arch/version-dependent stuff under /usr/lib or
 /usr/libexec, and the other data under /usr/share/qt5 or similar.
 That is also how both qt4 and qt5 ports have done things, and there is
 zero need to change that to make the ports co-installable.

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


More information about the macports-tickets mailing list