Le Fri, Oct 24, 2025 at 10:27:21AM +0200, Rafael Sadowski a écrit :
> 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?

well, i don't know, but looking for _autogen or AUTOGEN in
https://github.com/qgis/QGIS/ doesnt yield much. nor moc_.

https://github.com/qgis/QGIS/blob/release-3_44/scripts/includemocs.py
has some bits,
https://github.com/qgis/QGIS/blob/release-3_44/scripts/sip_include.sh#L39
others... all this feels like voodoo.

but at least now i know why it doesnt behave like expected :)