VS Code Support Updates, master branch (2019.11.28.)

This is an update from !28323 (merged), trying to address the complaints of @rbielski. (Wasted quite some time on it this morning...)

The new configuration teaches VS Code how to open a custom CentOS 7 container, which can then be used both by the user to compile packages (using the WorkDir project) against a numbered release or nightly, and by VS Code to interpret our code. (It makes use of the compiler set up inside of the container.)

The way it works is the following:

• You need a full clone of the athena repository (as stated in !28323 (merged), we may want to follow up with @karolos about teaching git-atlas about this later on);
• You need to create a directory called build/ just beside this clone (for debugging, and for performance it makes sense to keep the build results on your easily accessible local disk);
• With those set up, you need to make sure that CVMFS is accessible on the host on which you'll be running VS Code. I looked quickly once again at how practical is would be to mount CVMFS inside the image itself, but that still doesn't seem to be a practical approach.
  • Note that the configuration mounts all 4 CVMFS repositories usually needed for software development explicitly, because just mounting /cvmfs inside the container caused all sorts of issues for me.
• At this point you can just start VS Code natively on your OS, from any environment (for instance just from the start menu works just fine), and then open the athena/ folder "using a container", as explained in: https://code.visualstudio.com/docs/remote/containers#_quick-start-open-an-existing-folder-in-a-container

Unfortunately after this you still have to follow a very specific path to make VS Code interpret the source files in the repository successfully. 😦

• You need to go to the /build directory in the terminal brought up by VS Code (cd /build);
• Here, set up the release/nightly that you want to build against (setupATLAS && asetup Athena,master,latest for instance);
• Now, set up a partial build of the package(s) that you want to develop.

What I've been doing for the last point was to copy WorkDir/package_filters_example.txt to /build, edit it on my host OS (since this directory is a physical directory on the host), and then execute:

cmake -DATLAS_PACKAGE_FILTER_FILE=package_filters_example.txt /workspaces/athena/Projects/WorkDir/

Once this command is finished, you are "ready".

• You can execute make, and it should successfully build the selected package(s) for you;
• You can go and open files from the package(s), and VS Code should be able to interpret the C++ source code correctly.

Like (on Ubuntu 18.04):

Or like (on macOS Mojave):

I do have to admit, that the procedure is not super easy still. 😦 But, it does allow "reasonable" code development on our repository on any reasonably configured Linux/macOS desktop/laptop. (Windows is not really an option because of a lack of native CVMFS support...)

Let me also tag @lheinric, as I know that he was also pretty interested in this feature of VS Code a while ago.

P.S. This mode is super slow on macOS. 😦 I have no idea why, but everything that I'm doing in the built-in terminal of VS Code on macOS, is ridiculously slow. (And uses a lot of CPU on the host.) Running the CMake configuration for TrigBunchCrossingTool took about 1 hour. Not joking... 😦 When I took the screenshot, my laptop was still losing its mind, trying to interpret that bloody source file... On Ubuntu the behaviour is pretty nice though. 😉