On Monday January 12 2015 19:25:35 Marko Käning wrote: > Weird though, that for some odd reason I couldn’t find your post in the > list’s administrative interface anymore. It got somehow trashed… :(
Heh, the odd reason is that I considered it wasn't necessary to flood everyone's inbox with a just-over-40K message concerning an error that's resolved. Well, almost resolved; my fix is to patch 2 .ninja files so they don't add -I/opt/local/include/qt5 to the search path, but it seems they can get re-generated. This is something to take up on a Qt ML; see my thread "qt 5.4 build failure to replace existing qt5.3 in the same place" in the archives at http://lists.qt-project.org/mailman/listinfo/interest . Another fix would be to change the MacPorts framework so it supports projects that cannot be build when an older version is present. That could be an extension of the conflicts_build feature, allowing ports to conflict with themselves, and deactivate the active version of those port before the configure step. The only tricky thing in that would be to reactivate the same version if the port command exits without having installed the new version. But I presume the MacPorts majority will consider it a bug in the project's build system that has to be fixed at that level ;) R. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
