passing it around via qt5.port.mk to setting it directly in the qtwebkit
port and setting PKGSPEC so that it's passed automatically.
test/ok rsadowski@
it maybe possible to get it building with -Wl,--no-keep-memory or maybe
by using ld.bfd instead of LLD, if someone wants to figure out the qmake/gn
bits needed I can test diffs
-ONLY_FOR_ARCHS = ${GCC4_ARCHS} ${CLANG_ARCHS}
+ONLY_FOR_ARCHS ?= ${GCC4_ARCHS} ${CLANG_ARCHS}
The only port changed by this is qtwebengine, making it honour the more
restrictive ONLY_FOR_ARCHS setting in its Makefile.
it to build.
[memory below the 4GB line is very limited on at least some modern
intel x86 processors as used in the package build cluster; according to
Dell systems with Skylake CPUs "allocate more memory" (to the hardware)
"as they are often configured with Thunderbolt capability" ...
"regardless of the system having actual Thunderbolt hardware" and
according to Acer they "reserve more memory for PCI-Express and MMIO
devices" - presumably same for Kaby Lake as in the build machines].
The following doc components are gone
- qtconnectivity
- qtdatavis3d
- qtdeclarative
- qtwebkit (The effort is no longer worth it)
All doc components are installed in separate directories
QtWebEngine is not yet enabled (hooked up) but this version works for the most
use-cases. Google maps, Youtube stream with sound, nextcloud... I have not
tested video conferences, this is not the main use case either.
Most applications do not use QtWebEngine to implement a browser but to interact
with certain HTTPS services/websites or for showing HTML docs.
Next tasks:
- Slowly switch and test some KDE5 applications from qtwebkit to qtwebengine
- py-qtwebengine
FYI: We're not going to switch otter-browser to QtWebEngine. Otter is the only
browser really working on macppc.
To be honest, this would never be possible without the incredible chromium
patches collection of robert@ and his input. So a lot of patches come from
www/chromium/patches and some form FreeBSD.
Changelog:
- https://github.com/qtwebkit/qtwebkit/releases/tag/qtwebkit-5.212.0-alpha4
Port changelog:
- Switch QT5_WEBKIT_VERSION from 5.212.0 to 5.212.0alpha4v0 which includes
an EPOCH bump.
- Switch to py3, MODPY_VERSION=${MODPY_DEFAULT_VERSION_3}
- upstream: "QtWebKit does not require Python 2 anymore for building and can
use Python 3 instead"
- Bump QT5_WEBKIT_VERSION/MODQT5_WEBKIT_VERSION consumer
sparc64 build by jca@ Thanks!
(which is not) throughout the ports Makefiles.
* Replace find|xargs with find -exec {} +
* Replace -exec {} \; with -exec {} + if applicable.
* Use the -delete operator to remove files and empty directories.
* Combine and tweak some find(1) invocations while here.
ok kn@ rsadowski@ espie@
cups is necessary to fix ALL Qt5 print dialogs and double-conversion to return
to the status quo. Cause I'm here, some Makefile cleanups.
Tweak by Vadim, thanks!
Notable changes:
The good:
- Most of the work was done in qtbase
- The qtbase port comes with zstd support by default enabled
- Switched from c++11 to c++17
- Option "-openssl-linked" works now, no more ssl,crypto dlopen()d
- All shred lib bumped to be safe
- Many cleaning jobs in the Makefiles
- Add a new Qt submodule: QtLottie
- qtcanvas3d submodule is gone
The bad:
- The docs package is broken for now and unhooked
- vulkan is disabled until arm64 is vulkanready.
- Still no qtwebengine. (That would be a full time job)
- system double-conversion is no longer found by the configure step.
- Be my guest to fix it.
The ugly:
- patch-qmake_generators_unix_unixmake_cpp
-- That was the biggest problem, at the p2k19 I decided to solve by:
"Transform /usr/ports/pobj/xxx/lib/libQt5Core.so into
-L/usr/ports/pobj/xxx/build-amd64/lib -lQt5Core" ... works!
Many thanks to all who made this possible and all the test hours!
Special thanks to sthen@, landry@, jca@ and cwen@
OK sthen@, landry@
QML API for rendering graphics and animations
Qt Lottie Animation provides a QML API for rendering graphics and animations
that are exported in JSON format by the Bodymovin plugin for Adobe After
Effects.
OK sthen@, landry@
5.212.0 comes from an independent project: https://github.com/qtwebkit/qtwebkit
It's a QtWebKit with a more modern WebKit code base which fix a lot of bugs and
security holes.
Notable port changes:
- Remove qtwebkit-examples, this can go away
- Build the old qtwebkit docs, there is no new one.
- Almost all patches can be removed. New patches come from NetBSD.
- Tweak: Remove TEST_*, there is no test suite.
- Tweak: Remove MACHINE_ARCH sh so keep in sync with www/webkitgtk4
powerpc (cwen@), sparc64 (jca@), amd64,i386 (landry@ and I)
Input and help by many. Great ports team effort!
qt5/docs may be marked BROKEN, dpb(1) will still try to download its
distfiles. I have checked that the checksums match other ports under
x11/qt5.
While here, also clean up REVISION as noted by sthen@
ok sthen@
Tested in an amd64 bulk build by naddy@ Thanks!
multimedia/qtav was fixed. Docs is still broken but fixes are comming soon.
Drop maintainer address because nobody controls the google mailing list
openbsd-kde@googlegroups.com.
there may be some missing as my unpacked ports source is a little out of date
but this should catch the main things people might run into
the struct was reordered a second time in sysctl.h r1.192 to improve
compatibility but amd64 snapshot packages made it out before that happened
so the bumps are still needed
a comment resulting in libtool scripts not being able to parse the line
correctly. Problem reported by Vadim Penzin. Use of 'endl' rather than
'\n' requested by rsadowski.
Bumps to follow for other ports using the qt5 module and including .la files.
Follow the upstream recommendations for packagers and switch to
multi-packages:
devel/gettext -> devel/gettext,-runtime
devel/gettext-tools -> devel/gettext,-tools
(new) devel/gettext,-textstyle
.qmlc and .jsc files cannot be built on !x86, breaking the packaging of
a few x11/qt5 subports on these archs. We're introducing here
MODQT5_COMMENT in a similar way to what python does with MODPY_COMMENT.
Tested on macppc amd amd64. Hints by George Koehler and landry@,
proposed by sthen@ (thanks you all!), applied by me.
OK landry@ rsadowski@
