Re: [ITA] cmake 3.12.0

[Tony Kelman <tony at kelman dot net>]

> No, all I'm saying that there's a protocol for that.  The maintainer is
> supposed to monitor this list

I do read the mailing list, but don't write to it very often - composing a
plain-text email is overly complicated with the mobile email clients I use
most of the time, and I was traveling this past week.

I haven't been maintaining cmake very well, I've seen and noted all the
requests for updates but haven't had time to refresh the package. Ivan's
request is the first one that sounds more like "how can I help do this"
rather than "please do this for me, why haven't you done this."

I agree with the "general rule [...] to not mail package maintainers
directly" but the plain-text requirements of the list and the limited
functionality of gmane nowadays at least made it simpler to respond to
a direct email that Ivan already sent me. To reiterate, and expand, my
response publicly now that I have regular access to a device from which
I can send plain-text emails:

One of the main reasons I haven't put in the effort to update the cmake
package is that recent versions of cmake have new dependencies which it
vendors by default, which is not the way distros such as cygwin prefer to
build things. For a cygwin packaging build of cmake (as with other tools),
the "right way" is presumably to use system versions of all library
dependencies. This would require an ITP on at least libuv, and any other
new dependencies of cmake that the latest version has but 3.6 didn't.
This might include rhash and json-cpp (looking at how msys2 has updated
their packaging of cmake over time), but I'm not positive.

If Ivan is willing to package and maintain libuv and any other new cmake
dependencies so they can be de-vendored, I'm fine with him adopting cmake.
For his own sake, I'd recommend doing a better job than I did of tracking
down any test failures and pursuing upstreaming the cygwin patches. Many of
those originate from Yaakov, and there is some past discussion on the list
about a few of them. Those patches are kind of a pain to rebase with each
new version, so working to upstream them will save time over the long run.

I haven't reviewed what Ivan has changed in the packaging, patches, etc.
So heavy cygwin users of cmake, particularly packagers of other cmake-built
programs and libraries, should carefully test out the new builds.

-Tony