Re: cmake version problem

[tlaronde%polynum.com@localhost]

Le Fri, Jul 21, 2023 at 06:35:51AM -0400, Greg Troxel a écrit :
> 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.

I'm not complaining: I'm only stating and this could avoid puzzling 
"bug" reports so help you (the pkgsrc developers or programmers).

And as a matter of "how" it can happen to be so: I'm using pkgsrc only
for some packages and, for my own software, I use neither pkgsrc nor
cmake.

Hence cmake is a dependency of some packages. If packages don't complain
about the cmake version (fortunately, a lot of packages don't use it),
since _I_ didn't install it, it may perfectly be that the packages
I installed from pkgsrc were building with this old version so it wasn't
noticed till then (plus there are very few packages added this way
and, furthermore, there was another node until recently running
NetBSD 9.3 with same arch on which I built, previously, packages;
having updated this one to 10.0_BETA and this one being not for
production, the other one had to work...).

>[...] 
> 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.
> 

IMHO (because I don't contribute except for patches), this seems a
reasonable compromise: won't update cmake every other week; but should
ensure that it is reasonably near the version used when bulk building on
binary servers so that builds successing in this up-to-date environment
should succeeds even on systems dragging reasonably behind.

And BTW, x11-links has been a problem too from time to time, because
when upgrading a node, it has to be rebuilt but an admin is not aware of
it.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C