> Em qua., 6 de mai. de 2020 às 09:53, Michael Paquier > <michael@paquier.xyz> escreveu: > > > On Tue, May 05, 2020 at 10:16:23AM +0300, Victor Wagner wrote: > > > I agree, it is better. > > > > Thanks, applied and back-patched down to 9.5. Now for the second > > problem of this thread.. > > > Sorry, no clue yet. > I hacked the perl sources, to hardcoded perl, bison and flex with > path.It works like this.
Perl has "magic" variable $^X which expands to full path to perl executable, I wonder why build.pl doesn't use it to invoke secondary perl scripts.
I still don't think it's necessary, it was working well.
My main suspicions are:
1. Path with spaces;
2. Incompatibility with < symbol, some suggest use "
<ExecCommand=""
3. Msbuid.exe It has been updated (version 16.5.0)
4. Perl scripts increased the level of security.
5. My user do not have administrator rights.
Cause found.
How it worked before
1. Call link from menu Visual Studio 2019: Auxiliary\Build\vcvars64.bat
That create a console with settings to compile on 64 bits.
2. Adjusting the path manually
set path=%path%;c:\perl\bin;c:\bin
3. Call build.bat
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.