[Bug 255007] www/qt5-webengine: 5.15.2 fails to build if 5.15.0 is installed (link error)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255007 --- Comment #5 from Adriaan de Groot --- "If you enjoyed this twisty maze of passages, all alike, you may also like: porting WebEngine away from Python2" In all seriousness, John, I appreciate your persistence in chasing this. It's a real pain in the butt to do (I recommend ccache and a large memory disk to alleviate it a little). (Do drop in on #kde-freebsd on Freenode's IRC network if you want to do some interactive maybe-this-will-work? kind of stuff -- assuming the regulars are awake & around) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 255007] www/qt5-webengine: 5.15.2 fails to build if 5.15.0 is installed (link error)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255007 --- Comment #4 from John Hein --- (In reply to John Hein from comment #3) As Adriaan pointed out and I also discovered, the Makefile.modules with the offending lib reference (/usr/local/lib/qt5/libWebEngineCore.so) is indeed created (by the twisty maze nearly opaque wall of qmake, make, and ninja, etc.) much nearer the end of the build stage than the beginning (and its long 2+ compile/etc. actions). This makes it harder to apply time-honored strategies that interpose fixes like patching generated Makefiles after the configure stage. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 255007] www/qt5-webengine: 5.15.2 fails to build if 5.15.0 is installed (link error)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255007 --- Comment #3 from John Hein --- (In reply to Adriaan de Groot from comment #1) Adriaan, I understand and agree with your comments. Thanks for the reply. I'll investigate a little to increase understanding and to see if some simple improvement can be applied that is actually helpful. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 255007] www/qt5-webengine: 5.15.2 fails to build if 5.15.0 is installed (link error)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255007 --- Comment #2 from John Hein --- Commenting out the QMAKEMODULES settings in qt.mk gets this working. That is, the build for qt5-webengine now sets compile / link flags to look for things (like the locally built libQt5WebEngineCore.so) in the work dir [1]. Based on some early investifation, it looks like if you define QMAKEMODULES, mkspecs/features/qt_build_config.pri the QMAKEMODULES can override the build's decisions for things like library paths (QT_MODULE_LIB_BASE). What we really wanted for the QMAKEMODULES stuff (I think) is to append to the default search so that it will look in the work dir then LOCALBASE if it doesn't find something. But it seems that the current qmake infrastructure (at least as used in qt5-webengine) already will look in the work dir if QMAKEMODULES is not set to override that mechanism. This explanation is a little hand wavy - I am inferring a lot of things I don't quite follow from beginning to end by looking at the end results. I am investigating removing this from qt.mk altogether (and running a large build in poudriere to test). Let me know what you think might break as a result, please. Or any other useful hints / historical perspective. [1] before commenting out QMAKEMODULES in qt.mk, the link command is: c++ ... -L/usr/ports/www/qt5-webengine/work/.build/lib -L/usr/local/lib /usr/local/lib/qt5/libQt5WebEngineCore.so ... after: c++ ... -L/usr/ports/www/qt5-webengine/work/.build/lib -L/usr/local/lib /usr/ports/www/qt5-webengine/work/.build/lib/libQt5WebEngineCore.so ... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 255260] Ports that have DOCS option but no actual docs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255260 Adriaan de Groot changed: What|Removed |Added Assignee|ports-b...@freebsd.org |k...@freebsd.org Status|New |In Progress CC||adr...@freebsd.org --- Comment #1 from Adriaan de Groot --- - json-glib was fixed in february by Tobias - aspell is still open - the rest will land with the Plasma 5.21.3 update, due "soon" -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 253447] devel/libphonenumber: build error for can not find 'google/protobuf/inlined_string_field.h'
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253447 Adriaan de Groot changed: What|Removed |Added CC||adr...@freebsd.org Resolution|--- |Not Accepted Status|New |Closed --- Comment #4 from Adriaan de Groot --- To add to what Tobias said: on Linux "everything" lives in `/usr/include`, which isn't explicitly added as an include path. It's implicitly a system-include path, just like on FreeBSD. But because we install all the non-system headers in `/usr/local/include`, that path needs to be added to the header search-path. That can be done with `-I` or `-isystem`, and as soon as that happens, it is both explicit, and somewhere specific in the search-order. So any package on FreeBSD that installs headers to `/usr/local/include` *and also* has any dependency with headers in `/usr/local/include` has a problem: the `-I` for `/usr/local/include` must come **after** any `-I` for the package's internal headers. Setting that up is something that very few package-build-system do (e.g. you need to be very very careful in handling include paths, whether you use autoconf, cmake or something else). Each individual package needs patching / massaging to get that right. And that's why "build in a clean environment" is the recommended and inexpensive workaround, and why patches for specific ports are welcome. libphonenumber is special, the build is also full of race-conditions, but that's because Google is awful. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 235195] x11/plasma5-plasma: Windows and menus do not redraw after upgrade
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235195 Adriaan de Groot changed: What|Removed |Added Status|Open|Closed Resolution|--- |Unable to Reproduce CC||adr...@freebsd.org -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
