From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Mingw task for Cirrus CI |
Date: | 2022-04-04 20:41:31 |
Message-ID: | 20220404204131.ujb2jtxxplknhtej@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2022-04-04 20:45:40 | Re: shared-memory based stats collector - v68 |
Previous Message | Mark Dilger | 2022-04-04 20:28:17 | Re: New Object Access Type hooks |