Re: Cygwin cleanup

Hi,

On 2022-11-08 19:04:37 -0600, Justin Pryzby wrote:
> From 2741472080eceac5cb6d002c39eaf319d7f72b50 Mon Sep 17 00:00:00 2001
> From: Justin Pryzby <pryzbyj(at)telsasoft(dot)com>
> Date: Fri, 30 Sep 2022 13:39:43 -0500
> Subject: [PATCH 1/3] meson: other fixes for cygwin
>
> XXX: what about HAVE_BUGGY_STRTOF ?

What about it? As noted in another thread, HAVE_BUGGY_STRTOF is defined in a
header, and shouldn't be affected by the buildsystem.

Pushed this commit.

> XXX This should use a canned Docker image with all the right packages
> installed? But if the larger image is slower to start, then maybe not...

I think once we convert the windows containers to windows VMs we can just
install both cygwin and mingw in the same image. The overhead of installing
too much seems far far smaller there.

> + CONFIGURE_FLAGS: --enable-cassert --enable-debug --with-ldap --with-ssl=openssl --with-libxml
> + # --enable-tap-tests

I assume this is disabled as tap tests fail?

> + C:\tools\cygwin\bin\bash.exe --login -c "cygserver-config -y"

I'd copy the approach used for mingw of putting most of this in an environment
variable.

> +findargs=''
> case $os in
> freebsd|linux|macos)
> - ;;
> + ;;
> +
> + cygwin)
> + # XXX Evidently I don't know how to write two arguments here without pathname expansion later, other than eval.
> + #findargs='-name "*.stackdump"'
> + for stack in $(find "$directory" -type f -name "*.stackdump") ; do
> + binary=`basename "$stack" .stackdump`
> + echo;echo;
> + echo "dumping ${stack} for ${binary}"
> + awk '/^0/{print $2}' $stack |addr2line -f -i -e ./src/backend/postgres.exe
> + #awk '/^0/{print $2}' $stack |addr2line -f -i -e "./src/backend/$binary.exe"
> + done
> + exit 0
> + ;;

Is this stuff actually needed? Could we use the infrastructure we use for
backtraces with msvc instead? Or use something that understands .stackdump
files?

> +++ b/src/test/perl/PostgreSQL/Test/Cluster.pm
> [...]
> +++ b/src/test/perl/PostgreSQL/Test/Utils.pm
> [...]
> +++ b/src/test/recovery/t/020_archive_status.pl
> [...]

I think these should be in a separate commit, they're not actually about CI.

Greetings,

Andres Freund