Use preinstalled Boost on Azure

[taketwo]

As discussed in #2928, use preinstalled Boost instead of installing through vcpkg.

This PR includes a temporary commit that fixes a problem with environment variables on Azure agents.

Maintainer Edit:

As I mentioned before, not all Azure runners have up-to-date images with Boost installed. Until this changes we should not merge this PR.

[taketwo]

It's probably unrelated to these commits, but most tests fail with an exception and 0x135 exit code:

  1/108 Test   #1: test_2d ................................Exit code 0xc0000135
***Exception:   0.04 sec

[UnaNancyOwen]

If pre-installed Boost is a dynamic link library, It may be /bin (%BOOST_ROOT%/bin).
Can you print the contents of BOOST_ROOT directory?

[taketwo]

Thanks for suggestion! It's ridiculous, but I just can not print the contents of BOOST_ROOT directory (or any other directory for that matter). For example, when I try to print Program Files, I get:

DIR %ProgramFiles(x86)%
##[command]"C:\windows\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "D:\a\_temp\1c168be6-d48b-4d7c-96e6-f6dc26fbdbd8.cmd""
File Not Found
File Not Found
 Volume in drive C is Windows
 Volume Serial Number is 5EA7-0AE1

 Directory of C:\


 Volume in drive D is Temporary Storage
 Volume Serial Number is 8CDE-F0B1

 Directory of D:\a\1\s


 Directory of D:\a\1\s

##[error]Cmd.exe exited with code '1'.

So for now I removed printing from the job. In the meanwhile I figured out how to properly update PATH environment variable. Let's see if having BOOST_ROOT\lib in the path will solve the original issue.

P.S. One other problem that complicates debugging is that apparently some of Azure runners have old images deployed that don't have Boost yet.

[taketwo]

I finally managed to get one of the jobs through: log. Seems like the problem with failing tests is solved by adding BOOST_ROOT\lib to the PATH.

As I mentioned before, not all Azure runners have up-to-date images with Boost installed. Until this changes we should not merge this PR.

In the meanwhile I have a few questions, maybe @UnaNancyOwen you can answer them:

1. Why do we need to add this directory to PATH explicitly? Shouldn't CMake take care of this?
2. Examining our environment variables, I realized that VCVARSALL is not properly set. In the log I referenced above you can see that it's set to VCVARSALL=%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvarsall.bat (note that program files path was not expanded!). Thus this line

   pcl/.ci/azure-pipelines/build-windows.yml

   Line 33 in 79ed336

   call "%VCVARSALL%" %ARCHITECTURE%

   does not do anything useful, right? Do we need it?
3. In the process of debugging this PR I discovered that PATH can not be modified by set PATH=... call. This means that this line

   pcl/.ci/azure-pipelines/build-windows.yml

   Line 34 in 79ed336

   set PATH=%VCPKG_ROOT%\installed\%PLATFORM%-windows\bin;%PATH%

   also has no effect and we can probably remove it. But why do we need to add Boost to PATH, but not vcpkg installation directory?

[UnaNancyOwen]

If pre-installed boost is dynamic link library, these test program needs to refer dlls at runtime. Therefor, It is necessary to add dlls location to environment variable Path. (In generally, It is /bin. I don't know why it is /lib.)
vcpkg has the feature to add post-build event to copy dependent dlls to directory that include in execute files after build. (however, it is only dependencies install by vcpkg.) Therefore, It was not required additional path when install all dependencies using vcpkg.

Probably, These are remnant of CI when using AppVeyor.
If these line are not required, I think we can remove.

[UnaNancyOwen]

@taketwo Are there other upstream changes to wait for?
Can we remove label "status: needs upstream fix"?
If can remove that label, I think this pull request ready to merge.

[SergioRAgostinho]

I think this was the reason

As I mentioned before, not all Azure runners have up-to-date images with Boost installed. Until this changes we should not merge this PR.

I'm not sure though how to verify when that happens.

[taketwo]

That's the reason, correct. We now have a "print environment variables" step and this can be used to check whether the agent has Boost installed. This is indicated by existence of BOOST_ROOT variable. For example, this job has it, and this job does not. We just need to keep an eye on this.

[UnaNancyOwen]

@SergioRAgostinho @taketwo I get it. 👌

[taketwo]

One other option that just came to my mind would be to have a step that checks if BOOST_ROOT is set and, if so, skips installation with vcpkg.

[taketwo]

I added conditional Boost install step, but apparently this condition does not work as expected:

condition: not(variables['BOOST_ROOT'])

In the last run x64 agent had Boost and x86 agent did not, but both executed the step. If there are any experts in Azure conditions, please chime in!

[taketwo]

I reported the issue of Boost not being available on all agents to Microsoft some days ago. They confirmed and fixed the issue. Therefore this one is finally good to go.