VS Code Support, master branch (2019.11.27.)

This is a "fun" MR, which I think many people in the Core SW group will enjoy. So let me tag a few people... @tsulaia, @ssnyder, @fwinkl, @leggett.

The MR makes it possible to use Visual Studio Code with the WorkDir project a bit more conveniently.

In order for VS Code to parse our code correctly, it has to be told explicitly how each source file needs to be compiled. (Otherwise it would not find the headers from LCG/TDAQ/Gaudi to interpret our code.) This update makes sure that when the user sets up the build of the WorkDir project in the "usual layout" (in a directory called build/ just beside the athena/ directory), VS Code would automatically find the correct compile_commands.json file that it needs when the user opens the athena/ directory for editing.

Resulting in an editing experience like:

Unfortunately this thing only works with partial builds at the moment, it doesn't work with partial checkouts. We would have to ask @karolos to include the .vscode directory in partial checkouts (if it exists). Unfortunately I didn't find an easy way of telling git-atlas to check it out for me.

The way I did the previous thing was:

git clone ...
mkdir build
cd build/
cmake -DATLAS_PACKAGE_FILTER_FILE=../package_filter.txt ../athena/Projects/WorkDir/
code

I.e. it's important to start VS Code from the same environment in which the build is to be performed. (Since the configuration I added in this MR makes use of the ${CXX} environment variable.)

P.S. It of course doesn't work on lxplus. At least not until they install VS Code on the lxplus machines. But on private CentOS 7 machines, that have VS Code installed, it works very nicely.

This merge request affects 1 package:

• Projects/WorkDir

Adding @rbianchi as watcher

added Build master review-pending-level-1 labels

CI Result SUCCESS (hash dbf8d5bb)

	Athena	AthSimulation
externals
cmake
make
required tests
optional tests

Full details available on this CI monitor view
Athena: number of compilation errors 0, warnings 0
AthSimulation: number of compilation errors 0, warnings 0
For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 6200]

Seems fine, approving. Eric, L1

added review-approved label and removed review-pending-level-1 label

merged

mentioned in commit 30d10407

Hi @akraszna, @fwinkl,

it's important to start VS Code from the same environment in which the build is to be performed.

what about users for whom this is not true? I run VSCode and develop athena natively on my Fedora, but compile and run within a CC7 docker container. My code editing is thus detached from compiling. Now my local config file conflicts with the one from the repository. When checking out from master, I get:

error: The following untracked working tree files would be overwritten by checkout:
	.vscode/c_cpp_properties.json
Please move or remove them before you switch branches.
Aborting
fatal: Could not detach HEAD

and when get the one from release and overwrite with my version, it appears as an unstaged change, even though I have .vscode in my $HOME/.gitignore.

This means users wanting to use VS Code in any other setup than the one assumed in this MR will have a problem. Looking at: https://stackoverflow.com/questions/23673174/how-to-ignore-new-changes-to-a-tracked-file-with-git
and in particular the comments in the accepted answer, there seems to be no good solution here other than removing these files from the repository?

Should we really have this as part of Athena? You could have the config file contents written in developers' guide page and anyone wishing to set up Athena + VSCode for themselves, could copy from there. And, more importantly, they could copy and then modify the settings according to their needs.

Hi Rafal,

How happy are you with that setup of yours? I can't imagine that it can find the LCG/TDAQ/Gaudi headers, can it? Or did you really hardcode into your private configuration where all of those things are?

I also found (on Ubuntu 18.04) that telling VS Code to use the same compiler that I use for the build, is very important. One gets a lot of issues when trying to use for instance GCC 7 with VS Code while the build is using GCC 8. (Since GCC 7 has a "lesser" implementation of C++17.)

So... what are you proposing? How else should we support VS Code if not like this? Again, this setup is the only setup that I found to make VS Code behave as a useful IDE. Otherwise it's really just a dumb text editor for our code.

Attila

I'm happy with my setup. I have a local checkout of the dependencies relevant for my work to get IntelliSense to understand my code:

{
    "configurations": [
        {
            "name": "Linux",
            "includePath": [
                "${workspaceFolder}/**",
                "/home/rafal/Documents/work/trigUpgrade/Gaudi/**",
                "/home/rafal/Documents/work/trigUpgrade/CORAL-master/src/**",
                "/home/rafal/Documents/work/trigUpgrade/atlas-tdaq-software/**"
            ],
            "defines": [],
            "compilerPath": "/usr/bin/gcc",
            "cStandard": "c11",
            "cppStandard": "c++17",
            "intelliSenseMode": "gcc-x64"
        }
    ],
    "version": 4
}

The code I depend on doesn't change that often, so I very rarely update those checkouts and still have a good experience.

My /usr/bin/gcc is 9.2.1 and I haven't experienced any issues due to that.

I'm suggesting to instruct users how to configure VSCode by providing them an example config file, rather than forcing it by having it in the repository. Perhaps some handy flag could be added to git atlas to set up such file automatically if one wants?

How is this solved for other large software projects with large dependencies in and outside HEP? Looking e.g. at ROOT, they don't have .vscode in the repo and actually they explicitly have it in .gitignore:
https://github.com/root-project/root/

If you're happy to keep setting up this file by hand every time you make a new clone of the repository, then how is my change making things any more complicated for you?!? Just overwrite the file, and use yours.

But everybody who is happy to use our central recommendations, will get it for free. Without having to find a TWiki, learn how to do this, and then do it on every git clone.

P.S. I guess none of the code that you ever edit ever needs a definition set from the compiler command line. In the analysis software we need that a lot. And this setup does this out of the box. (Letting VS Code know when XAOD_ANALYSIS, XAOD_STANDALONE, and similar definitions are set for the build.)

Well, the problem is that now I will never have clean git status. There will always be this hanging unstaged change leading to issues with checking out branches, rebasing, etc

git update-index --assume-unchanged .vscode/c_cpp_properties.json (from that SO thread I posted) is a kind of workaround for this problem, but as also stated there, has limitations. Now I will not be able to check out any tag/branch from before this MR was merged, and I will also have to face issues whenever this file gets updated on either side (me or athena).

That is:

$ git status
On branch test1
nothing to commit, working tree clean
$ git checkout nightly/master/2019-11-26T2131 
error: Your local changes to the following files would be overwritten by checkout:
	.vscode/c_cpp_properties.json
Please commit your changes or stash them before you switch branches.
Aborting

Sure, maybe I will be fine and just briefly annoyed sometimes, but I'm still not convinced to the idea of IDE settings being part of the source tree in the repository.

Just found this:
https://code.visualstudio.com/docs/remote/containers

I will investigate if this is a feasible option for merging our worlds.

added sweep:ignore label

I just started playing with that. First success: Tab-completion of eg. StatusCode works!

• Walter

mentioned in merge request !28348 (merged)

mentioned in merge request !42629 (merged)