| | 4 | |
| | 5 | EDIT: |
| | 6 | Adding QwtFramework to QWT_CONFIG doesn't change anything in what gets installed. That's the first time I'm seeing this kind of behaviour with a qmake-based project. It looks that I do get a correct build against Qt4 (with the frameworks in Qt's Frameworks directory), but only when I use the qmake PortGroup. Without that, qmake-qt4 complains about the --prefix argument; I'm not sure why that wouldn't happen with the official Qt4 port and PortGroup. |
| | 7 | |
| | 8 | In any case, I'd say that qwtconfig.pri should contain `QWT_INSTALL_PREFIX`, `QWT_INSTALL_HEADERS` etc. definitions that are set following the `qt_dir`, `qt_includes_dir` variables from the Qt PortGroup. |
| | 9 | |
| | 10 | EDIT2: With Qt5, in order for the frameworks to be installed, one has to use `QT_INSTALL_LIBS` (with my Qt5 build but also with the official 5.4 install I still have around): |
| | 11 | |
| | 12 | {{{ |
| | 13 | > /opt/local/libexec/qt5/qmake -query QT_INSTALL_FRAMEWORKS |
| | 14 | **Unknown** |
| | 15 | Exit 101 |
| | 16 | }}} |
| | 17 | |
| | 18 | Doing this will put the frameworks under ${prefix}/libexec/qt5/, as one would hope. |
| | 19 | Of course this means different qwtconfig patchfiles are required for Qt4 and Qt5, or a else a reinplace of QT_INSTAL_FRAMEWORKS for Qt5. |
| | 20 | |
| | 21 | That does *not* change the issue with the incomplete id in the generated frameworks. I'll look into that, I think there's a module one can include (or config to add) to store an absolute rpath, so that post-destroot magic isn't required. |
