Re: increasing cmake requirement?

[Greg Troxel <gdt%lexort.com@localhost>]

"Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost> writes:

> Am Fri, 21 Jul 2023 12:33:05 -0400
> schrieb Greg Troxel <gdt%lexort.com@localhost>:
>
>> > I guess 3.18, 3.19 are fine. Building CMake once every few years might
>> > be not too much to ask.  
>> 
>> Thanks.  I amend my proposal to >=3.18 then.
>
> Anyhow: Regarding minimum sensible CMake version, the current practice
> of employing BLA_PREFER_PKGCONFIG and BLA_PKGCONFIG_BLAS /
> BLA_PKGCONFIG_LAPACK as documented in
>
> 	https://cmake.org/cmake/help/latest/module/FindBLAS.html
> 	https://cmake.org/cmake/help/latest/module/FindLAPACK.html
>
> means that our usage of mk/blas.buildlink3.mk providing BLAS_PC and
> LAPACK_PC and used by a number of packages now relies on a minimum
> CMake version of 3.25. More strictly, this could be 3.23.2nb1 as the
> versions that first carried our local patches for the same feature.

There is a difference between the default minimum for any use of cmake,
and a package that uses cmake declaring that it needs a higher version.
I am not sure we have support for that, but it is essentially like
including a bl3 and then setting API_DEPENDS.

> Also, once I add support for the C API stuff via local patches,
> possibly, when I make the first package rely on this, I need to update
> the cmake version requirement, too, I presume. I did not think about
> that back when I first added the FindBLAS changes. Should this then be
> done locally only in the affected package?

I see this as shades of grey rather than having a right answer.
Certainly, if a package needs recent cmake than the global requirement,
we have to express that locally.

Personally, I see it as bad practice to have a set of packages installed
that are not all consistent with a particular pkgsrc version.  But,
that's not our doctrine, and our "need recent enough foo" is an
accomodation for it.

> Generally, it's rather dangerous to have old versions of cmake around
> if one depends on the detection machinery for various dependencies that
> it carries.

Generally, it is used for that!

> But for the upcoming stable branch at least it should be ensured that
> the packages that got converted to use BLA_PREFER_PKGCONFIG get the
> correct machinery. My intention is to have that in all CMake-using
> packages relying on BLAS.

Changing global cmake version requirements seems well beyond appropriate
in freeze.  Fixing packages is fine.

In my view, the most important thing is if the pkgsrc sources, when
built from no packages as in pbulk, produce correct and working
packages.  In that environment, the current cmake will be used and
that's 3.28.1.  So there is no acute problem and we are talking about
people who ahve a system with some random collection of outdated
packages and update to 2023Q4 sources and then type make in some other
package, without first bringing their system up to date.

If you want to mark particular packages that use cmake as needing
whatever version they need, in a way that doesn't cause any other
problems, that seems like a valid fix.



Longer term, we can talk about how much we want to accomodate people
having old cmake installed and trying to make that work, vs just saying
cmake has to be 3.25 or 3.23.2nb1 always.  While I personally don't
think it's wise to have old/new packages mixed, if it's just adding a
CMAKE_VERSION_REQUIRED kind of line to the packages that are troubled by
blas finding issues, that seems like a minor effort to avoid the debate :-)