Re: cmake version problem

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

tlaronde%polynum.com@localhost writes:

> FWIW, when compiling some packages (pkgsrc-2023Q2), the compilation
> failed with a puzzling message about some dir or some file (like
> ".../work/cmake-build-..."; I didn't write it down, so it's from memory
> and likely partly incorrect) not existing.
>
> It happened that the cmake version on the building node was 3.9.
> Updating to 3.26 solved the problem.
>
> So it seems the verification cmake-[0-9]* should be more strict: there
> are apparently incompatibilities at least in the way some upstream
> software or some pkgsrc packages use the building tree or expect it to
> be.

While you are technically correct that these limits should perhaps be
different:

  pkgsrc as used by just about everybody who contributes has an
  expectation that packages are reasonably up to date, and ~nobody
  spends time worrying about trying to build packages with 2023Q2
  sources with installed binary packages from 5 years ago (cmake was
  updated to 3.10 in March of 2018!).  The standard approach is to pkgin
  ug from binary packages, do your own pbulk and use that, use pkg_rr,
  or something equivalent.

  Each package has its own requirements about what cmake version it
  needs.  Often these are not documented.  Adding a line to the package
  to represent this is in theory reasonable, but I suspect in the grand
  scheme of things is more noise and misdirected effort than useful.

Currently the requirement (in /usr/pkgsrc/mk/tools/replace.mk) is

  cmake>=2.8.1nb1

and indeed that is unreasonably crufty.

We could change it to 3.19, reflecting end of 2020 pkgsrc, and a version
recent enough that any upstream that can't build with 3.19 is IMHO
buggy.