linear_algebra PortGroup does not automatically add configure args

[barracuda156]

Installing dbcsr on another machine, and linking again is wrong: despite Accelerate being default (and recognized as such), configure.args to link against vecLibFort are not passed at all, and CMake opportunistically links to OpenBLAS.

--->  Configuring dbcsr
Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_dbcsr/dbcsr/work/build" && /opt/local/bin/cmake -G "Ninja" -DCMAKE_BUILD_TYPE=MacPorts -DCMAKE_INSTALL_PREFIX="/opt/local" -DCMAKE_INSTALL_NAME_DIR="/opt/local/lib" -DCMAKE_SYSTEM_PREFIX_PATH="/opt/local;/usr" -DCMAKE_C_COMPILER="$CC" -DCMAKE_CXX_COMPILER="$CXX" -DCMAKE_OBJC_COMPILER="$CC" -DCMAKE_OBJCXX_COMPILER="$CXX" -DCMAKE_POLICY_DEFAULT_CMP0025=NEW -DCMAKE_POLICY_DEFAULT_CMP0060=NEW -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_COLOR_MAKEFILE=ON -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_MAKE_PROGRAM=ninja -DCMAKE_MODULE_PATH="/opt/local/share/cmake/Modules" -DCMAKE_PREFIX_PATH="/opt/local/share/cmake/Modules" -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON -DCMAKE_INSTALL_RPATH="/opt/local/lib" -Wno-dev -DPython_EXECUTABLE=/opt/local/bin/python3.11 -DFYPP_EXECUTABLE=/opt/local/bin/fypp-3.11 -DUSE_MPI=ON -DUSE_OPENMP=ON -DUSE_SMM=blas -DWITH_C_API=ON -DWITH_CUDA_PROFILING=OFF -DBUILD_TESTING=ON -DTEST_OMP_THREADS=2 -DTEST_MPI_RANKS=4 -DWITH_EXAMPLES=OFF -DCMAKE_OSX_ARCHITECTURES="ppc" -DCMAKE_OSX_DEPLOYMENT_TARGET="10.6" -DCMAKE_OSX_SYSROOT="/" /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_dbcsr/dbcsr/work/dbcsr-2.5.0 

-- Performing Test _openblascheck_has_OMP
-- Performing Test _openblascheck_has_OMP - Success
-- Found BLAS: /opt/local/lib/libopenblas.dylib 

Of course, I could manually set arguments in the portfile to force correct behavior, but perhaps rather PG should be fixed.

This should have been passed by PG:

        cmake_linalglib         -DBLAS_LIBRARIES=vecLibFort \
                                -DLAPACK_LIBRARIES=vecLibFort

16. S. For a note, while my example happens to be from 10A190, incidentally, the ticket does not refer to a particular OS version, but to interaction of PG with CMake.

[barracuda156]

Okay, identical behavior on stock 10.6.8 (expectedly):

[barracuda156]

And yes, I faced the same issue when making linalg port, had to add args into portfile: ​https://github.com/macports/macports-ports/blob/2c4bce43700c7d4ca14a207817e2476996a8f524/math/linalg/Portfile#L41 So PG is broken.

[barracuda156]

Hmm, admittedly I forgot about this part:

#   in pre-configure, a line like this may be needed:
#   configure.args-append --with-blas="-L${prefix}/lib ${linalglib}"
#   or
#   configure.args-append ${cmake_linalglib} (for CMake)

But why not add configure.args directly?

[kencu (Ken)]

It appears the PortGroup expects the Portfile authour to figure out which of the various configure args are needed in a given port, and add them once the right ones are known.

So this is not exactly a "broken" portgroup...

Because other ports might well BARF when they see configure args added that they don't accept, I'm not sure changing this to automatically add a bunch of them (all of them?) makes a lot of sense...

[barracuda156]

Replying to kencu:

It appears the PortGroup expects the Portfile authour to figure out which of the various configure args are needed in a given port, and add them once the right ones are known.

So this is not exactly a "broken" portgroup...

Because other ports might well BARF when they see configure args added that they don't accept, I'm not sure changing this to automatically add a bunch of them (all of them?) makes a lot of sense...

You are right, thank you for a correction.

[kencu (Ken)]

Things with PortGroups are often less than 100% clear. They are helpful, for sure, and many do their thing just by adding the PortGroup. Yet others require reading the PG code to see what is needed to make them work, and some PortGroups require almost intimate knowledge of the internals to really get them to work.