From: Jeremie Courreges-Anglas <jca@wxcvbn.org>
Subject: Re: clang.port.mk: fix detection of clang-scan-deps
To: Rafael Sadowski <rafael@sizeofvoid.org>
Cc: ports@openbsd.org, phessler@openbsd.org, Theo Buehler <tb@theobuehler.org>
Date: Wed, 8 Jul 2026 23:15:19 +0200

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?
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. ;)

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