From: | Victor Wagner <vitus(at)wagner(dot)pp(dot)ru> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Postgres Windows build system doesn't work with python installed in Program Files |
Date: | 2020-05-07 05:04:53 |
Message-ID: | 20200507080453.757a8eef@antares.wagner.home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
В Thu, 7 May 2020 09:14:33 +0900
Michael Paquier <michael(at)paquier(dot)xyz> пишет:
> On Wed, May 06, 2020 at 03:58:15PM -0300, Ranier Vilela wrote:
> > Hacking pgbison.pl, to print PATH, shows that the path inside
> > pgbison.pl, returned to being the original, without the addition of
> > c:\perl\bin;c:\bin. my $out = $ENV{PATH};
> > print "Path after system call=$out\n";
> > Path after system
> > call=...C:\Users\ranier\AppData\Local\Microsoft\WindowsApps;;
> > The final part lacks: c:\perl\bin;c:\bin
> >
> > Now I need to find out why the path is being reset, within the perl
> > scripts.
>
> FWIW, we have a buildfarm animal called drongo that runs with VS 2019,
> that uses Python, and that is now happy. One of my own machines uses
> VS 2019 as well and I have yet to see what you are describing here.
> Perhaps that's related to a difference in the version of perl you are
> using and the version of that any others?
I doubt so. I have different machines with perl from 5.22 to 5.30 but
none of tham exibits such weird behavoir.
Perhaps problem is that Ranier calls vcvars64.bat from the menu, and
then calls msbuild such way that is becames unrelated process.
Obvoisly buildfarm animal doesn't use menu and then starts build
process from same CMD.EXE process, that it called vcvarsall.but into.
It is same in all OSes - Windows, *nix and even MS-DOS - there is no
way to change environment of parent process. You can change environment
of current process (and if this process is command interpreter you can
do so by sourcing script into it. In windows this misleadingly called
'CALL', but it executes commands from command file in the current
shell, not in subshell) you can pass enivronment to the child
processes. But you can never affect environment of the parent or
sibling process.
The only exception is - if you know that some process would at startup
read environment vars from some file or registry, you can modify this
source in unrelated process.
So, if you want perl in path of msbuild, started from Visual Studio,
you should either first set path in CMD.EXE, then type command to start
Studio from this very command window, or set path via control panel
dialog (which modified registry). Later is what I usially do on machines
wher I compile postgres.
--
> --
> Michael
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2020-05-07 05:05:10 | Re: BUG #16419: wrong parsing BC year in to_date() function |
Previous Message | Michael Paquier | 2020-05-07 04:49:45 | Re: Should smgrdounlink() be removed? |