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
