qca and qca-ossl adaptations to qt4-mac +concurrent

[RJVB (René Bertin)]

port:qca and port:qca-ossl use hard-coded paths to Qt4 install locations, instead of using the variables provided by the qt4 PortGroup. That breaks installation when qt4-mac is installed +concurrent.

Patches are attached to this ticket.

[RJVB (René Bertin)]

Re: qca.diff: if a Portfile cannot verify properly whether an optional dependency is installed, that might be an argument to turning qt4-mac-transitional back into a variant. Other ports may also want to replace a moved shared library (plugin, etc) with a symlink to the object in its new location...

[sicherha@…]

Cc Me!

[mkae (Marko Käning)]

Cc Me!

[mkae (Marko Käning)]

How about this one, René, can these patches be committed without doing any harm to the current qt4-mac port?

[RJVB (René Bertin)]

It should be fine, the changes not protected by a test boil down to setting the default explicitly if you see what I mean. But let me check if I shouldn't update the patches. They're 6 months old by now.

[RJVB (René Bertin)]

somewhat more polished version hopefully less politically incorrect too

[RJVB (René Bertin)]

Replying to rjvbertin@…:

It should be fine, the changes not protected by a test boil down to setting the default explicitly if you see what I mean. But let me check if I shouldn't update the patches. They're 6 months old by now.

All fine as far as I can see. port:qca contains a context-sensitive variant that is made the default when my qt4-mac-transitional port is installed. That's not entirely politically correct, but as it's a temporary feature (and that transitional port is not currently a published port) I'm hoping it dosing raise too much ire.
Alternatively I presume I could obtain the variant's effect (creation of a single symlink) in a post-activation stage.

[RJVB (René Bertin)]

Edit: diffs for qca-gnupg and qca-cyrus-sasl2 are now attached.

I also see that QCA itself has been updated to 2.1.0 . I'll see if that's a transparent update and if so, what extra work is required to extract the source for the plugins which are now included with the main tarball. If they're small and build by default, shouldn't we simply install them with the main port and mark the qca plugin ports as replaced_by qca?

[RJVB (René Bertin)]

I've uploaded an initial version of an update to QCA 2.1.0 to my github repo. Only thing not tested yet are the universal builds. There appear to be no API changes, but I haven't yet done extensive testing of existing applications against the new library version.

Anyone interested in trying this new version?

[mkae (Marko Käning)]

Replying to rjvbertin@…:

port:qca contains a context-sensitive variant that is made the default when my qt4-mac-transitional port is installed.

So, what about removing the variants which aren't published to MacPorts (yet) in this case?

[RJVB (René Bertin)]

Do as you wish ...

[mkae (Marko Käning)]

@Michael: Can we commit this?

[michaelld (Michael Dickens)]

Please give me a few days to catch up (from being on vacation the last few weeks) & I'll check these out & do some commits. QCA has been on my queue for a long time to get updated, and if René's patches do the trick then I'm all for them.

[RJVB (René Bertin)]

Michael, in case it got snowed under in your inbox, let me repeat I'll be on "Qt4 standby duty" for about a week from now.

Also, if someone else could test my version to give Michael a hand, that'd be swell (at least a port destroot to see if there are any issues up to that point).

[michaelld (Michael Dickens)]

René: Yes, I'm kinda snowed under both in emails as well as MP updates to review and/or install; it might be a day or 2 before I get to the Qt4 stuff. I appreciate you doing standby duty; I'm sure we'll need folks to address Qt4 build issues once the changes are in place. Does what you wrote mean you are available for the next week or starting in about a week? I'm hoping the latter, which would actually be a good match for my current schedule.

[RJVB (René Bertin)]

Actually I was more thinking the next 7 days or so. We're having family over in 7 days, which may or may not take all my time, and we have no definite plans for what will happen thereafter. Which might mean we'll be off to my mom's very soon, but we'll see.

Can one deduce from once the changes are in place that you intend to let the build bots take care of the bulk of the Qt ports to be rebuilt? Figuring out by hand why select ports don't build is much less incompatible with being on a vacation than testing by hand if all ports build ;)

[michaelld (Michael Dickens)]

I'm hoping that we can rev-bump many of the qt4-mac dependencies to take care of 90%+ of the dependent ports. I'm quite sure there will be difficult ones, which is where having folks on standby to help with the load will be useful. I think I can start working on this Tuesday, with the goal of committing Wednesday or Thursday depending on complexity. This ticket's issue will likely be included in one of the final commits, to get it working with the new Qt4 location. Good luck with your family!

[RJVB (René Bertin)]

Hmmm, does one need to rev-bump anything when you upgrade qt4-mac to 4.8.7 in addition to making it concurrent?

There'd be the issue of qt4-mac-sqlite3-plugin should you decide to follow our suggestion to move it back into the main port (and dunk the sqlite2 plugin which appears both obsolete and unused). But I think that one can be handled with a replaced_by and the obsolete portgroup.

[michaelld (Michael Dickens)]

This ticket's issue has been fixed/surpassed by r145233.

[RJVB (René Bertin)]

Please verify against the changes I posted a few weeks back and that are required for KF5 (​https://trac.macports.org/ticket/49109).

[michaelld (Michael Dickens)]

Hmm ... well, the only thing installed into the Qt4/Qt5 directory is the mkspec file. Everything else is installed into just ${prefix} subdirectories. The plugins are installed into /opt/local/share/qca/plugins/crypto . None of the plugins have a self-id according to otool. Not sure what else is needed. Can you test to verify that they work?

[RJVB (René Bertin)]

QCA provides Qt plugins, so logically they'd have to go into Qt's plugins directory. That's where they're installed in my version of the port, and I don't see a good reason to change that. I also saw mention of a framework build, which I presume concerns the libraries of the main port. All in all that sounds like changes that are going to force rebuilds on all qca dependents, which include huge ports like kdelibs4 ... which would explain the issues Marko is reporting. I find that a damn good reason to refrain from making mostly cosmetic changes to install locations, which includes moving to a frameworks build as a default.

What I can do is see what happens when I combine these new build principles with my own set-up (your port doesn't provide Qt5 versions or subports for the plugins, does it?).

[RJVB (René Bertin)]

On a more general note, re: the comments on Debug builds. Qt's debug+release frameworks builds really seem geared towards people who do development on Qt itself. They're very cumbersome to use for debugging dependent software in my experience (I couldn't get dyld to load all _debug framework "payloads") and is just about as viral as +universal in that it causes all dependents to build that way. This is not related to the issue at hand, but just how many MacPorts users have a need to do full source-level debugging of Qt code? I know only one -- me O:-), and I simply use a release build with debug info. That's good enough; I can step through the code and then decide where I have to add qDebug() calls to inspect C++ variables. I don't think that a full debug build would make it easier to understand what's going on in code that makes such extensive use of class instances which are almost impossible to inspect in a debugger (that's not gdb).