From: Rafael Sadowski <rafael@sizeofvoid.org>
Subject: Re: cleanup/reorder cmake.port.mk
To: Landry Breuil <landry@openbsd.org>
Cc: ports@openbsd.org
Date: Fri, 24 Oct 2025 10:27:21 +0200

On Fri Oct 24, 2025 at 10:21:49AM +0200, Landry Breuil wrote:
> Le Fri, Oct 24, 2025 at 10:14:05AM +0200, Rafael Sadowski a écrit :
> > On Fri Oct 24, 2025 at 09:38:47AM +0200, Theo Buehler wrote:
> > > On Fri, Oct 24, 2025 at 07:11:51AM +0200, Rafael Sadowski wrote:
> > > > Before we commit cmake4, I would like to have cmake.mk reviewed
> > > > and committed separately.
> > > > 
> > > > 1. I would prefer not to have CMAKE_AUTOGEN_PARALLEL at the
> > > >    beginning, all by itself, before the actual configure arguments
> > > >    are set.
> > > 
> > > Sure.
> > > 
> > > > 2. Nothing uses "samurai". If anyone wants to use it, they can set
> > > >    USE_NINJA=No and CONFIGURE_ARGS += -DCMAKE_MAKE_PROGRAM=samu
> > > >    themselves. I don't want that in the module.
> > > > 
> > > > 2.1 Once "samurai" is gone, we can write the first if-else
> > > >     cleanly. If Ninja otherwise ‘Unix Makefiles’ The second large
> > > >     block is the one without else. This also makes it easier to read.
> > > 
> > > I don't really understand this. I don't see a massive improvement in
> > > cleanliness or readability coming from dropping one .elif, one || and
> > > two additional lines. I think a single port using samurai will have
> > > to deal with more complexity than that.
> > > 
> > > Then again I don't feel strongly about having to support samu right now
> > > and would also be fine with adding this logic back when samu is needed.
> > > 
> > 
> > Thanks for the feedback. Another idea would be to combine the two
> > if-else blocks into one:
> > 
> > 
> > Index: cmake.port.mk
> > ===================================================================
> > RCS file: /cvs/ports/devel/cmake/cmake.port.mk,v
> > diff -u -p -r1.86 cmake.port.mk
> > --- cmake.port.mk	20 Feb 2025 15:28:27 -0000	1.86
> > +++ cmake.port.mk	24 Oct 2025 08:11:39 -0000
> > @@ -13,20 +13,10 @@ CONFIGURE_ENV += MODCMAKE_USE_SHARED_LIB
> >  MAKE_ENV += MODCMAKE_USE_SHARED_LIBS=yes
> >  .endif
> >  
> > -# Limit the number of moc/uic processes started by cmake_autogen
> > -# (default: number of CPUs on the system)
> > -CONFIGURE_ARGS += -DCMAKE_AUTOGEN_PARALLEL=${MAKE_JOBS}
> 
> sorry for hijacking a bit, but does this chunk proved actually useful ?
> building geo/qgis, i still see shittons of moc processes, fighting for
> cpu with other cpp processes...
> 
> running top during the build shows how painful that is.

Yes, it does, but ONLY if upstream uses the moc/uic functions
integrated in CMake:
https://cmake.org/cmake/help/latest/manual/cmake-qt.7.html#origin-autogen

The question is, how does upstream utilise this?