Hi,
On 2022-09-05 06:50:55 -0500, Justin Pryzby wrote:
> I saw that but hadn't tracked it down yet. Do you know if the tar
> failures were from a TAP test added since you first posted the mingw
> patch, or ??
I think it's that msys now includes tar by default, but not sure.
> Also: your original patch said --host=x86_64-w64-mingw32, but the task
> is called MinGW64. The most recent patches don't use --host at all, and
> were building for a 32 bit environment, even though the OS image says
> MSYSTEM=UCRT64.
I don't think you should need to use --host, that indicates cross compiling,
which we shouldn't do. I don't think the patch without --host targets 32bit -
the last time CI ran the patch, it built a 64bit PG:
https://cirrus-ci.com/task/5489471041830912?logs=configure#L231
[13:47:54.539] checking size of void *... (cached) 8
[13:47:54.557] checking size of size_t... (cached) 8
and the underlying commit didn't specify --host.
> Also: right now src/test and src/interfaces/*/test aren't being built
> during the build phase, which means that they're 1) not compiled in
> parallel; and 2) not cached. This isn't specific to MinGW. Other than
> compiling those dirs specifically, one option is to put
> "always: upload_caches: ccache" after "test_world_script" (in that case,
> if the CI instance is rescheduled during tests, the compilation won't be
> pushed to cache). Actually, it seems better to compile stuff during
> "build" or else any compilation warnings should up in the middle of
> "check-world.."
I'd tackle that independently of this commit.
> Also: I'm having second thoughts about the loop around ./configure. It
> could happen that a cached configure would succeed, but then the build
> would later fail, and it wouldn't fix itself. I think a slow configure
> is okay for an "opt-in" task.
Agreed.
I think we can convert this to meson soon, and that seems a *lot* faster at
configure than autoconf on mingw. Not even close to as fast as on a modern-ish
linux, but not that painful.
Greetings,
Andres Freund
