Re: Mingw task for Cirrus CI - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Mingw task for Cirrus CI
Date
Msg-id 20220404204131.ujb2jtxxplknhtej@alap3.anarazel.de
Whole thread Raw
In response to Re: Mingw task for Cirrus CI  (Andres Freund <andres@anarazel.de>)
Responses Re: Mingw task for Cirrus CI  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Hi,

On 2022-03-30 17:26:18 -0700, Andres Freund wrote:
> Hi,
>
> On 2022-03-22 19:00:42 +0300, Melih Mutlu wrote:
> > Rebased it.
> > I also removed the temp installation task and
> > used NoDefaultCurrentDirectoryInExePath env variable instead.
>
> Hm. But you're still using a separate build directory, from what I can see?
> The NoDefaultCurrentDirectoryInExePath thing should only have an effect when
> not using a separate build directory, no?

Melih chatted with me about making this work. Turns out it doesn't readily -
pg_ctl still fails.


The reason that NoDefaultCurrentDirectoryInExePath doesn't suffice to get a
working in-tree build, is that we break it ourselves:

int
find_my_exec(const char *argv0, char *retpath)
...
#ifdef WIN32
    /* Win32 checks the current directory first for names without slashes */
    join_path_components(retpath, cwd, argv0);
    if (validate_exec(retpath) == 0)
        return resolve_symlinks(retpath);
#endif

So even if windows doesn't actually use the current path, and the current
pg_ctl process isn't the one from the current directory, we *still* return
that.

Gah.


Maybe we should just use GetModuleFileName()?


But even after that the tests don't work. Commands started via IPC::Run do,
but when using system() they don't. Looks like perl parses the path the itself
:(.

- Andres



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: New Object Access Type hooks
Next
From: "David G. Johnston"
Date:
Subject: Re: shared-memory based stats collector - v68