[MacPorts] #47994: gnuplot +qt5: build failure
MacPorts
noreply at macports.org
Tue Jun 9 04:51:04 PDT 2015
#47994: gnuplot +qt5: build failure
----------------------------+---------------------
Reporter: jinxiaoyong@… | Owner: mojca@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version:
Resolution: | Keywords:
Port: gnuplot |
----------------------------+---------------------
Comment (by rjvbertin@…):
So it seems mcalhoun did reuse my version of the qt5 portgroup definition
(with many thanks again for [not] mentioning this nor soliciting any final
feedback).
The following mess-up is almost bound to lead to issues too:
{{{
#file=qt5-1.0.tcl
[...]
# standard install directory
global qt_dir
set qt_dir ${prefix}/libexec/qt5-mac
[...]
global qt_archdata_dir
set qt_archdata_dir ${qt_dir}
[...]
set qt_dir ${prefix}/libexec/${qt_name}
#
}}}
So after setting a new variable `qt_archdata_dir` (which I fail to see the
exact meaning of) to ${prefix}/libexec/qt5-mac, `qt_dir` and a whole slew
of variables are redefined to use `${prefix}/libexec/qt5` as in my
implementation. I think (but haven't bothered to check) that this must
lead to having both directories under ${prefix}/libexec being used, which
is completely unnecessary. Even if it doesn't, there is still the global
`qt_archdata_dir` variable that's "exported" and that is likely to lead to
confusion at some point down the road.
Again, I don't see the point of that variable. Qt itself (through the
qtchooser utility) distinguishes between a QTTOOLDIR (where tools like
qmake are expected) and a QTLIBSDIR (where the binary libraries are
expected). The former is the most important and corresponds to
`qt_bins_dir`, the latter evidently corresponds to `qt_libs_dir`. See my
submission for port:qtchooser. There's simply no need for an additional
"archdata" concept.
--
Ticket URL: <https://trac.macports.org/ticket/47994#comment:8>
MacPorts <https://www.macports.org/>
Ports system for OS X
More information about the macports-tickets
mailing list