charm-qt5 @1.8.0_20150312: cannot evaluate portfile

[larryv (Lawrence Velázquez)]

% port version
Version: 2.3.99
% sudo port clean charm
Password:
--->  Cleaning charm
% sudo port clean charm-qt5
Error: Unable to open port: can't read "qt_apps_dir": no such variable

[mkae (Marko Käning)]

Oh, René, another side-effect of the current concurrent qt5-mac? :(

[Ionic (Mihai Moldovan)]

The variable is commented out in the qt5 PortGroup, but not in the qt4 PortGroup. port is right to complain.

[Ionic (Mihai Moldovan)]

Introduced in r137229, btw.

[mkae (Marko Käning)]

Fabulous, so, how to recover smoothly from this one?

[RJVB (René Bertin)]

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.

[RJVB (René Bertin)]

-        if {[file exists ${qt_frameworks_dir}/QtCore/QtCore]} {
-            depends_lib-append path:Library/Frameworks/QtCore/QtCore:qt5-mac
+        if {[file exists ${qt_frameworks_dir}/QtCore.framework/QtCore]} {
+            depends_lib-append path:libexec/${qt_name}/Library/Frameworks/QtCore.framework/QtCore:qt5-mac
         } else {
-            depends_lib-append path:lib/libQtCore.5.dylib:qt5-mac
+            depends_lib-append path:libexec/${qt_name}/lib/libQtCore.5.dylib:qt5-mac

That looks like another error, since qt_frameworks_dir is set to ${qt_libs_dir} which is ${qt_dir}/lib .

I also note that qt_cmake_modules_dir is not set by the mainstream portgroup.

[mkae (Marko Käning)]

Is the above to be added to the diff? If so, could you update the diff?

The diff (at least) seems to have quite many changes... Is that going to be compatible with the current qt5-mac port?

Do you mean by "(and rebuild)", that we have to revbump qt5-mac and let the builder chew through that?

[mkae (Marko Käning)]

I am afraid that the change to the qt5 portgroup calls for a dedicated ticket...

Well, I'm adding the usual Qt* suspects for this kind of ticket to get more audience. :)

[RJVB (René Bertin)]

Replying to mk@…:

Is the above to be added to the diff?

No, that's an extract from the diff, highlighting something I think must be an error in the current portgroup (lines starting with '-').

The diff (at least) seems to have quite many changes...

As I said, many of those changes are simply due to the fact I've reorganised the file a bit so relevant things are easier to catch. Most of that is grouping the path variables' global declaration and explanatory comment together, and the actual definitions in another block.

Is that going to be compatible with the current qt5-mac port?

If you mean with the current Portfile: I think it should. I added the one variable I noticed that was introduced (qt_archdata_dir) and my version didn't have. It should also work with dependent ports.

Do you mean by "(and rebuild)", that we have to revbump qt5-mac and let the builder chew through that?

Basically, yes. If ever there's an opportune moment for such a thing it'd be one like now, I guess - especially if the bump to Qt 5.4.2 is still waiting.

PS: now might also be a good time to decide whether or not you want to follow Bradley's suggestion to re-integrate the sqlite3 plugin into the main port. The main port actually depends on it, and Qt's build process supports building it along with the rest. (It's actually more complicated to build those plugins separately.)

PS2: about that chewing-through: that can be reduced roughly in half by removing qtwebengine from the standard Qt5.4+ build (reduces the software archive by some 35% too; the installed footprint probably by even more). QtWebengine is new in Qt 5.4, so it was rather natural to handle that by moving it to a dedicated subport.

[mkae (Marko Käning)]

Pixilla, could you apply this patch on your VM and test whether the current qt5-mac can rebuild fine with these changes for the qt5 portgroup? (Sorry, I won't manage that test tonight anymore...)

[RJVB (René Bertin)]

Replying to mk@…:

Pixilla, could you apply this patch on your VM and test whether the current qt5-mac can rebuild fine with these changes for the qt5 portgroup? (Sorry, I won't manage that test tonight anymore...)

Had I known this request would be made I wouldn't have set it to build the current qt5-mac port to check it out. I'll make the preparations at least. Real pity that mcalhoun didn't copy my change to build Qt5 "out-of-source", I'd have had to rewind the process only the configure step rather than completely. Remember, port configure took over an hour with the VM's current configuration ...

EDit: I'll start a port destroot; actual installation would mean deactivating the ports currently installed and I'd prefer to do that myself.

[RJVB (René Bertin)]

heads-up: it seems the build process is now churning through QtTools only. IIRC that's the component built just after QtBase, so it's not unlikely this is going to run for the rest of the day.

I did run into an issue with the block below, but that was the only thing I had to and did fix (change) before launching the build. We'll have to see if QtWebengine builds too, there appears to be more "magic" applied to that component than I found necessary.

    # see #44934 (and #35067 for the qt4-mac version)
    if { true } {
        set framework_list [split ${qt_frameworks_dir} '/']
        set qt_list        [split ${qt_dir} '/']

        while {[llength ${qt_list}] && [llength ${framework_list}]} {
            set var_qt        [lindex $qt_list        0]
            set var_framework [lindex $framework_list 0]

            if { ${var_qt} ne ${var_framework} } {
                break
            }

            # remove first element from list
            set qt_list        [lreplace ${qt_list}        0 0]
            set framework_list [lreplace ${framework_list} 0 0]
        }
        set libreplace [string repeat ../ [llength ${qt_list}]][join ${framework_list} /]
        # RJVB: reinplace should be done in the post-patch
        post-patch {
            if { ${libreplace} ne "lib" } {
                patchfiles-append patch-shared.diff
                reinplace "s|__MACPORTS_FRAMWORK_DIR__|${libreplace}|g" ${worksrcpath}/qttools/src/macdeployqt/shared/shared.cpp
            }
        }
    }

the reinplace was being done unconditionally, even while doing port info or port lint. It's probably coincidence this worked with the author's setting for qt_frameworks_dir.

About that block: I haven't tried to understand what the Tcl code does exactly. Compared to Michael's fix, it seems rather construed; in Qt4 the macdeployqt issue could be fixed with a very simple patch to the source code without any reinplacing, possibly because of his choice of setting for the location of the frameworks. I do wonder about the utility though. macdeployqt is for creating autonomous app bundles. Is that a supported use for MacPorts (I guess I don't have to enumerate here what MacPorts features and principles are borked by bundling of this kind)?

[RJVB (René Bertin)]

Status update: the port finished building and installs with my PortGroup.

However, there is at least 1 issue in the Portfile itself: it overrides qt_frameworks_dir with the result that the frameworks do not end up in the intended (and published) location. In addition, the port doesn't create the .dylib links to the framework binaries that the qt4-mac (and my qt5-mac-devel) port create with undoubtedly good reason.

I will need to figure out where/how the Portfile needs to be amended, and post a patch. I hope to have some time for that this weekend.

[RJVB (René Bertin)]

Oh, this is great. I'm still waiting for qt5-mac 5.4.1 to rebuild, and rather than wait for the outcome and any ensuing decisions, the port has been bumped to 5.4.2 .

If I were paranoid I'd conclude someone is trying their best at thwarting any recognition for my work.

[RJVB (René Bertin)]

proposed amended Qt5 portgroup

[RJVB (René Bertin)]

As far as I can see I have now managed to create a minimal set of changes to the qt5-mac Portfile that allow the port to build as I would advise based on my testing of the past 5-6 months. From what I have been able to see it is now exchangeable with my own qt5-devel (qt5-mac-devel) port. It's a bigger changeset than I expected because the qt5 port was missing some of the post-destroot logic also used by qt4-mac to provide standard shared libraries in addition to frameworks.

Here is once more the amended qt5 PortGroup in "absolute" form, and a patch for the Portfile commenting the changes and also containing a number review comments throughout the file concerning points I feel need to be addressed. (Those are identified with my 4CC, which are evidently not intended to be committed "as is").

Testing was started and completed with Qt 5.4.1; I am now rebuilding everything once more with Qt 5.4.2 .

[RJVB (René Bertin)]

FWIW:

> /opt/local/bin/qmake-qt5 -query
QT_SYSROOT:
QT_INSTALL_PREFIX:/opt/local
QT_INSTALL_ARCHDATA:/opt/local/libexec/qt5
QT_INSTALL_DATA:/opt/local/share/qt5
QT_INSTALL_DOCS:/opt/local/share/doc/qt5
QT_INSTALL_HEADERS:/opt/local/include/qt5
QT_INSTALL_LIBS:/opt/local/libexec/qt5/Library/Frameworks
QT_INSTALL_LIBEXECS:/opt/local/libexec/qt5/libexec
QT_INSTALL_BINS:/opt/local/libexec/qt5/bin
QT_INSTALL_TESTS:/opt/local/share/qt5/tests
QT_INSTALL_PLUGINS:/opt/local/share/qt5/plugins
QT_INSTALL_IMPORTS:/opt/local/share/qt5/imports
QT_INSTALL_QML:/opt/local/share/qt5/qml
QT_INSTALL_TRANSLATIONS:/opt/local/share/qt5/translations
QT_INSTALL_CONFIGURATION:/opt/local/etc/qt5
QT_INSTALL_EXAMPLES:/Applications/MacPorts/Qt5/examples
QT_INSTALL_DEMOS:/Applications/MacPorts/Qt5/examples
QT_HOST_PREFIX:/opt/local
QT_HOST_DATA:/opt/local/share/qt5
QT_HOST_BINS:/opt/local/libexec/qt5/bin
QT_HOST_LIBS:/opt/local/libexec/qt5/Library/Frameworks
QMAKE_SPEC:macx-clang
QMAKE_XSPEC:macx-clang
QMAKE_VERSION:3.0
QT_VERSION:5.4.1

Note how the install and host prefix now correspond to the MacPorts prefix rather than pointing to ${prefix}/libexec/qt5 . This seems less ambiguous, and from what I remember I indeed ran into issues related to this setting when I started to make Qt4 co-installable (and at first put all of Qt4 in ${prefix}/libexec/qt4 like the current qt5-mac port does).

[RJVB (René Bertin)]

updated for Qt 5.4.2

[mkae (Marko Käning)]

Finally I was - in a 1st step - able to update the current qt5-mac on my VM. That left me puzzled, as it suddenly needs the x11 variant for pulseaudio per default. Is that a bug or intended?

Rebuilding charm in the process succeeded, but it crashes when run:

Process:         Charm [84123]
Path:            /Applications/Charm.app/Contents/MacOS/Charm
Identifier:      com.kdab
Version:         ???
Code Type:       X86-64 (Native)
Parent Process:  launchd [172]
Responsible:     Charm [84123]
User ID:         501

Date/Time:       2015-06-19 08:09:49.355 +0200
OS Version:      Mac OS X 10.9.5 (13F1077)
Report Version:  11
Anonymous UUID:  8B90C2A1-54FD-0810-3AAD-E7AF67C41FDC


Crashed Thread:  0

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  Library not loaded: /opt/local/Library/Frameworks/QtCore.framework/Versions/5/QtCore
  Referenced from: /Applications/Charm.app/Contents/MacOS/Charm
  Reason: image not found

Binary Images:
    0x7fff6adbf000 -     0x7fff6adf2817  dyld (239.4) <7AD43B9B-5CEA-3C7E-9836-A06909F9CA56> /usr/lib/dyld

[RJVB (René Bertin)]

Replying to mk@…:

Finally I was - in a 1st step - able to update the current qt5-mac on my VM. That left me puzzled, as it suddenly needs the x11 variant for pulseaudio per default. Is that a bug or intended?

I'd call it an intended bug ;) It's simply because mainstream qt5-mac is configured to use pulseaudio (PA) because that'd be the default *if PA is installed*. Evidently someone only interested in Qt and KDE applications (probably) won't have that port installed, so it and its dependencies are pulled in.

Rebuilding charm in the process succeeded, but it crashes when run:

Dyld Error Message:
  Library not loaded: /opt/local/Library/Frameworks/QtCore.framework/Versions/5/QtCore
  Referenced from: /Applications/Charm.app/Contents/MacOS/Charm
  Reason: image not found

That shouldn't happen with either version of the co-installable Qt5 port: it's looking for the QtCore framework in its old, "exclusive" location. This error could arise when you forgot to install charm after building it, or if for some reason the previous version got re-activated. It's of course possible too that the charm Portfile does things in the post-destroot that cause this error, which would IMHO suggest an issue with the mainstream Qt5 PortGroup.

I'm a bit surprised also by charm's install location: I'm pretty sure that my initial port proposition had it install to /Applications/MacPorts/Qt{4,5}, not to /Applications. Did you change that?

[mkae (Marko Käning)]

Replying to rjvbertin@…:

That shouldn't happen with either version of the co-installable Qt5 port: it's looking for the QtCore framework in its old, "exclusive" location. This error could arise when you forgot to install charm after building it, or if for some reason the previous version got re-activated.

OK

It's of course possible too that the charm Portfile does things in the post-destroot that cause this error, which would IMHO suggest an issue with the mainstream Qt5 PortGroup.

Hmm...

I'm a bit surprised also by charm's install location: I'm pretty sure that my initial port proposition had it install to /Applications/MacPorts/Qt{4,5}, not to /Applications. Did you change that?

Oh, if I did, it didn't happen on purpose. Needs checking.

[mkae (Marko Käning)]

The current version of the charm-qt5 sub-port contains:

configure.args-append   -DCharm_VERSION="${version}" -DBIN_INSTALL_DIR:PATH=${qt_apps_dir}

which should be all right, no!?

[mkae (Marko Käning)]

So, despite setting BIN_INSTALL_DIR in (or because of it appears in the common part) port:charm-qt5's port file as shown above, as wells as upgrading qt5-mac:

$ port installed qt5-mac charm-qt5
The following ports are currently installed:
  charm-qt5 @1.9.0rc1_0 (active)
  qt5-mac @5.4.2_1 (active)

I still get the same error!

Here's what the port installs:

$ port contents charm-qt5
Port charm-qt5 contains:
  /opt/local/bin/charmtimetracker
  /opt/local/libexec/qt5-mac/bin/Charm.app/Contents/Info.plist
  /opt/local/libexec/qt5-mac/bin/Charm.app/Contents/MacOS/Charm
  /opt/local/libexec/qt5-mac/bin/Charm.app/Contents/Resources/Charm.icns
  /opt/local/share/applications/charmtimetracker.desktop
  /opt/local/share/doc/Charm/License.txt
  /opt/local/share/doc/Charm/ReadMe.txt
  /opt/local/share/icons/hicolor/128x128/apps/Charm-128x128.png

so nothing lands in /Applications ATM.

[RJVB (René Bertin)]

You get the same error about /Applications/Charm.app while port:charm installs elsewhere? That means the one in /Applications is a left-over and should be removed...

What does the mcalhoun PortGroup set ${qt_apps_dir} to? And the charm port, what does it do in the post-destroot (too lazy to check right now ;))

[mkae (Marko Käning)]

OK, will do that, presumably, Monday.

Well, concerning ${qt_apps_dir} I thought things were sorted by now for qt5-mac... Will have to check.

[mkae (Marko Käning)]

Current port qt5-mac sets

/opt/local/libexec/qt5-mac/bin

for ${qt_apps_dir}. Is that correct?

[RJVB (René Bertin)]

I think the current mainstream portgroup does indeed, but I wouldn't say that's correct ;)

[RJVB (René Bertin)]

upgrade to 1.11.0, fix of the Qt4 build and cleanup

[mf2k (Frank Schima)]

Your patch does not apply. Please re-submit your patch against the latest git version.

[mf2k (Frank Schima)]

In 4cfd81b17ee9a6575a155ff4c92039acd6c9ab7e/macports-ports:

charm: Update to version 1.11.0

• Use cmake 1.1 portgroup
• Improve compatibility with qt5 portgroup

See: #47197
Fixes: #48024

[RJVB (René Bertin)]

Not fixed I notice. I missed a couple of opportunistic dependencies (yay for build systems that don't show dep they found) and I'm now getting a build error I cannot make much sense of ATM.

EDIT: that build error was because of another hidden opportunistic dependency, one you do NOT want to pick up.

This was always mostly Marko's port, I tinkered with it in its early days but never found any use for the application so lost interest. If someone wants to take over maintainership I'd appreciate that.

[mf2k (Frank Schima)]

Once again, please re-submit against the latest version of the Portfile in GitHub.