Em qua., 6 de mai. de 2020 às 15:19, Ranier Vilela <ranier...@gmail.com>
escreveu:
> Em qua., 6 de mai. de 2020 às 14:14, Victor Wagner <vi...@wagner.pp.ru>
> escreveu:
>
>> В Wed, 6 May 2020 10:21:41 -0300
>> Ranier Vilela <ranier...@gmail.com> пишет:
>>
>> > Em qua., 6 de mai. de 2020 às 09:53, Michael Paquier
>> > <mich...@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 "
>
> <Exec Command=""
>
> 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.
Cause: PATH being reset.
regards,
Ranier Vilela
