Re: [PATCH 0/3] Make CMake work out of the box

Hi Philip,

On Fri, 18 Jun 2021, Philip Oakley wrote:

On 18/06/2021 14:42, Johannes Schindelin wrote:

quoted

quoted

quoted

We already exercise the plain Makefile plenty, and the CMake-based build
using Windows (in the `vs-build` job in `.github/workflows/main.yml`).

There is one 'gotcha' in the yml (probably historical) in that it
doesn't actually test the approach/changes that Matt addresses regarding
my [1].

That is, I'm looking at the 'out of the box' view, while the yml test
_preloads_ the vcpkg artefacts.

We need to "pre-load" them because building them would add another
whopping 20 minutes to each CI run. And I am not talking total time, but
wall-clock time.

And we're not in the business of testing vcpkg's build.

So I am really not in favor of even thinking about changing this
"pre-loading" strategy.

I can see the common sense in that, however I was trying to highlight
that the approach in patch series could go stale, as did the previous
method. Making the entry ramp to investigating the code for the wide
variety windows users should have _some_ testing..

I don't have any good ideas about how to get out of that 20 minute
Catch-22 issue at the moment. Maybe it needs an independent, on-demand
(i.e. infrequent;-) test.

Maybe there is a way of adding a `--CI-test` option that at least
exercises the logic without needing the vcpkg to be built again (IIRC,
and I may well be wrong, we build once, remember the artefacts, and then
re-used them, but .. dunno).

I would strongly discourage tacking this onto the current CI. It is way
too rare a use case to merit adding the cost for all developers using the
CI runs to verify their work.

All is not lost, though: interested parties (such as yourself!) can easily
add their own GitHub workflows in their own repositories and verify that
things work.

You could even put the workflow on a timer, and add a matrix job that
builds `maint`, `master`, `next` and `seen`, to verify that things work.

And for extra brownie points, you can monitor the runs and work on fixes
whenever you see breakages. That would definitely take a good chunk of the
maintenance burden off of the Git maintainers.

Ciao,
Dscho