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
