Re: Postgres Windows build system doesn't work with python installedin Program Files

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема Re: Postgres Windows build system doesn't work with python installedin Program Files
Дата
Msg-id CAEudQAqT29gENiTqCuW4X7KZy+g5a7yBnB4=1rQCAdRGqCk_Tw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Postgres Windows build system doesn't work with pythoninstalled in Program Files  (Victor Wagner <vitus@wagner.pp.ru>)
Список pgsql-hackers
Em qui., 7 de mai. de 2020 às 02:04, Victor Wagner <vitus@wagner.pp.ru> escreveu:
В Thu, 7 May 2020 09:14:33 +0900
Michael Paquier <michael@paquier.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.
The perl is the same,when it was working ok.
 

Perhaps problem is that Ranier calls vcvars64.bat from the menu, and
then calls msbuild such way that is becames unrelated process.
It also worked previously, using this same process, link menu and manual path configuration.
What has changed:
1 In the environment, the python installation, which added entries to the path.
2. Perl scripts: Use perl's $/ more idiomatically
commit beb2516e961490723fb1a2f193406afb3d71ea9c
3. Msbuild and others, have been updated.They are not the same ones that were working before.
 

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.
Maybe that's what is happening, calling system, perl or msbuild, would be creating a new environment, transferring the path that is configured in Windows, and not the path that is in the environment that was manually configured.
 

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.
buidfarm aninal, uses a more secure and reliable process, the path is already configured and does not change.
Perhaps this is the way for me and for others.

It would then remain to document, to warn that to work correctly, the path must be configured before entering the compilation environment.

regards,
Ranier Vilela

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: [PATCH] Keeps tracking the uniqueness with UniqueKey
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Should smgrdounlink() be removed?