From: Rafael Sadowski <rafael@sizeofvoid.org>
Subject: Re: clang.port.mk: fix detection of clang-scan-deps
To: ports@openbsd.org, phessler@openbsd.org,  Theo Buehler <tb@theobuehler.org>
Date: Thu, 9 Jul 2026 07:13:33 +0200

On Wed Jul 08, 2026 at 11:15:19PM +0200, Jeremie Courreges-Anglas wrote:
> On Tue, Jul 07, 2026 at 06:44:32PM +0200, Rafael Sadowski wrote:
> > On Mon Jul 06, 2026 at 10:21:12AM +0200, Jeremie Courreges-Anglas wrote:
> > > 
> > > As reported by phessler:
> > > 
> > >   audio/openal: /bin/sh: /usr/local/bin/clang-scan-deps-22: not found
> > > 
> > > and as analyzed by tb:
> > > 
> > >   [cmake] walks the path with clang-scan-deps-22.1, then clang-scan-deps-22, then clang-scan-deps. so if llvm/22 is installed, that takes priority.
> > > 
> > > clang-scan-deps is detected in the same manner as ar and ranlib in
> > > /usr/local/share/cmake/Modules/Compiler/Clang-FindBinUtils.cmake so
> > > the diff below uses the same approach to force the use of the
> > > executable from base.  All our architectures with ports-clang also
> > > ship base-clang and thus clang-scan-deps, so while slightly incorrect
> > > I think this is good enough.
> > > 
> > > With this, the openal build no longer fails if llvm%22 is installed at
> > > configure time and then removed.  ok?
> > > 
> > > 
> > > Index: cmake.port.mk
> > > ===================================================================
> > > RCS file: /home/cvs/ports/devel/cmake/cmake.port.mk,v
> > > diff -u -p -r1.91 cmake.port.mk
> > > --- cmake.port.mk	13 May 2026 07:10:23 -0000	1.91
> > > +++ cmake.port.mk	6 Jul 2026 08:19:18 -0000
> > > @@ -165,6 +165,7 @@ _CMAKE_PROCESSING_LANGUAGE = ASM OBJCXX 
> > >  .for LANG in ${_CMAKE_PROCESSING_LANGUAGE}
> > >  CONFIGURE_ARGS :=	-DCMAKE_${LANG}_COMPILER_AR:FILEPATH=/usr/bin/ar \
> > >  			-DCMAKE_${LANG}_COMPILER_RANLIB:FILEPATH=/usr/bin/ranlib \
> > > +			-DCMAKE_${LANG}_COMPILER_CLANG_SCAN_DEPS:FILEPATH=/usr/bin/clang-scan-deps \
> > >  			${CONFIGURE_ARGS}
> > >  .endfor
> > >  
> > > -- 
> > > jca
> > > 
> > 
> > Now we end up with a longer list of use-less informations:
> > 
> > CMake Warning:
> >   Manually-specified variables were not used by the project:
> > 
> >     CMAKE_ASM_COMPILER_AR
> >     CMAKE_ASM_COMPILER_CLANG_SCAN_DEPS
> >     CMAKE_ASM_COMPILER_RANLIB
> >     CMAKE_Fortran_COMPILER_AR
> >     CMAKE_Fortran_COMPILER_CLANG_SCAN_DEPS
> >     CMAKE_Fortran_COMPILER_RANLIB
> >     CMAKE_OBJCXX_COMPILER_AR
> >     CMAKE_OBJCXX_COMPILER_CLANG_SCAN_DEPS
> >     CMAKE_OBJCXX_COMPILER_RANLIB
> >     CMAKE_OBJC_COMPILER_AR
> >     CMAKE_OBJC_COMPILER_CLANG_SCAN_DEPS
> >     CMAKE_OBJC_COMPILER_RANLIB
> >     PYTHON_EXECUTABLE
> >     PYTHON_INCLUDE_DIR
> >     PYTHON_LIBRARY_DIRS
> >     Python3_EXECUTABLE
> >     Python3_INCLUDE_DIR
> >     Python3_LIBRARY_DIRS
> > 
> > I dont think it makes sense to define this for objc, objcxx, c or even
> > Fortran.
> 
> Well I implemented it that way *on purpose*.
> 1. I use the same approach as for ranlib and ar because the logic in
>   the cmake files is exactly the same.  Why isn't the noise about ar
>   and ranlib a problem?

Because the list keeps getting longer and real mistakes get lost in the
mix.

> 2. audio/openal does the check for both C and C++, I found leaving the
>   C case unhandled inconsistent.
> Granted, I should have be explicit about the additional warnings. ;)

Yes, I also spent some time thinking about the "C" case. I ended up
discarding it because I couldn't reconcile modules and C.

> 
> Also, I know next to nothing about ObjC, but apparently ObjC also has
> modules and clang apparently supports them[0].  I'd guess that the same
> would be true for ObjC++.
> 
> So nope, not ok.  Instead, do you know of any cmake magic that would
> silence those rather pointless warnings?
> 
> [0] https://clang.llvm.org/docs/Modules.html#objective-c-import-declaration
> -- 
> jca

The ObjC case is completely valid. Thanks for pointing that out. I'd be
in favor of leaving it as is.