Windows build: fix vswhere.exe command to find cl.exe

[vmo6trl]

The '-products *' option is now necessary to find cl.exe.

[touilleMan]

Hi @vmo6trl !

Thanks for this PR, can you explain why this option -product * does ?

I have to say this vswhere tool is a rather obscure and lacking documentation (even if the maintainer disagree on that 😄 )

Do you think your change would solve issue #48 ?

[vmo6trl]

Hi @touilleMan,

Sorry but I have no idea why this became necessary since as you pointed out there is no clear documentation available, I had to add this option to make it work on a Windows 10 virtual machine with Visual Studio 2017 installed and on a Windows Server 2019 image with Visual Studio 2022 installed on Appveyor CI. Without the option the command was returning no results at all but I had no delay to obtain the failure.

If you are interested to test the change using a patch in you CI with delay issue, you might find useful the following patch (using PowerShell command):

ps: (get-content autopxd/__init__.py) | %{$_ -replace '"-latest",','"-latest", "-products", "*",'}  | set-content autopxd/__init__.py

For information I also had issues with the C11 atomic types introduced by the pycparser with MSVC compiler and I also used this patch in autopxd2 installation sources to make it work on windows platform:

# C11 atomic types in _fake_typedefs.h of pycparser are not supported, retrieve previous version of the file in pycparser project
ps: (get-content setup.py) | %{$_ -replace 'commit = .*','commit = "a5e1958d4ab975057e0ce5358d1ac0329bb0cf74"'}  | set-content setup.py

Note that it worked perfectly fine on my Windows VM at first since I had a GCC installed from the GNAT compiler and I only realized the issue on the Appveyor CI that only had Visual Studio.

I also tried to find documentation on the initial version of Visual Studio or vswhere that introduced the need to add the "product" option to open this PR but without any success.

Best regards.