Re: Mingw task for Cirrus CI

From: Andres Freund <andres(at)anarazel(dot)de>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: Mingw task for Cirrus CI
Date: 2022-09-05 23:52:17
Message-ID: 20220905235217.5x4qyziidu4ofvzy@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2022-09-06 00:10:21 Re: Reducing the chunk header sizes on all memory context types
Previous Message Tom Lane 2022-09-05 23:50:22 Re: Modernizing our GUC infrastructure