On 2020/10/14 11:22, a...@sdf.org wrote:
> On Wed, Oct 14, 2020 at 10:06:34AM +0100, Stuart Henderson wrote:
> > What is the actual port you are trying to build, is it something where
> > it might be possible to remove qt5 from the chain instead of fixing
> > qt5 build?
>
> ===> poppler-20.09.0 depends on: qttools-*
>
> In print/poppler/Makefile you have
>
> NOT_FOR_ARCHS-qt5 = arm
>
> But there is no condition to this
>
> MODULES+= x11/qt5
>
> so qttools is pulled in.
Diff to fix that below. kili, ok?
Index: Makefile
===================================================================
RCS file: /cvs/ports/print/poppler/Makefile,v
retrieving revision 1.161
diff -u -p -r1.161 Makefile
--- Makefile 9 Sep 2020 20:16:44 -0000 1.161
+++ Makefile 14 Oct 2020 13:06:19 -0000
@@ -42,7 +42,9 @@ cWANTLIB= expat freetype fontconfig jpeg
MODULES= devel/cmake
+.if ${BUILD_PACKAGES:M-qt5}
MODULES+= x11/qt5
+.endif
# devel/boost only as build+run dependency, poppler uses
# header-only classes (from boost/containers/small_vector.hpp)
> But I'm here, lets take a look, qt is popular and it could fix a
> lot of packages, QtWebkit|QtWebengine could be useful in a machine
> with more ram... etc.
It's still pretty limited. RAM available to a single process is limited
by MAXDSIZ which is 1GB on armv7. Maybe qtwebkit can be got to work with
some effort, qtwebengine, which includes most of chromium, doesn't even
build on i386 (uses too much RAM), very unlikely to happen on OpenBSD on
32-bit arm.
> > I am asking because bulk builds on armv7 already take about 40 days - it
> > is pretty much pointless building snapshot packages on an architecture
> > with that kind of latency (OpenBSD library ABI is not really stable
> > so you will be lucky to get packages that work with a given snapshot
> > unless you save snaps from before each library bump).
> >
> > Fixing things to enable qt5 will make this situation even worse. Even if
> > you don't care about snapshots, this would further delay packages being
> > available after "base release" of a new OS version.
>
> You don't have a way to blacklist ports in the bulk build system?
No. Plus, a relatively complex port which isn't built in bulk builds is
unlikely to stay working for any length of time.
> Just for curiosity, what machine are you using to build the armv7
> packages?
A cluster of 4GB Cubox-i systems.
Contrast with arm64 which is very different. There is actual proper
server hardware available to use for builds for this; two machines do
a full bulk build in a couple of days, generating more packages than
are available on i386.
