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.
