Editor integrations in LSST sconsUtils


(Jim Bosch) #1

How would people feel about having sconsUtils targets that generate files useful for editor integrations?

I’ve already got a script for VSCode+Python that works okay as something I run manually, but build integration would both make it more convenient and provide a nice way to make it available to others.

I started looking into doing the same for C++ today, but it looks like trying to tell VSCode about C++ include paths without doing something inside sconsUtils is probably impossible. I assume the same is true for any other editor, because you can’t currently process our dependency-declaration information (the stuff in ups/<package>.cfg) without actually being inside a SCons script.

I haven’t thought this through in detail, but I’m thinking maybe having explicit targets for different editors, maintained on a totally volunteer basis, which would write whatever files are helpful for that editor. Those targets would of course not be included in the default build target.

An alternative might be to just have sconsUtils export any information an editor or other tool might want in a generic format. I don’t know of any well-established standard for that for C++, aside from perhaps CMake’s CMAKE_EXPORT_COMPILE_COMMANDS JSON format - but that isn’t something editors can necessarily read natively, and it would require downstream tools to parse information out of command-line arguments that sconsUtils knows directly. A custom format might be better, such as a JSON or YAML file that maps more directly to the SCons environment content.


(Tim Jenness) #2

Would DM-9029 help: replace sconsUtils “.cfg” with pkg_config?


(Jim Bosch) #3

It’d make it bit cleaner - you could then write tooling for editors without putting it in our build tooling, just as if we had sconsUtils export something generic, but at least for me it’d probably make it slightly harder to implement, because then I’d have to learn how to extract that information recursively from pkgconfig. More importantly, I don’t want to make the better the enemy of the good enough - I can imagine adding sconsUtils support for VSCode in a couple of hours, and I could imagine DM-9029 lingering indefinitely.


(Russell Owen) #4

I’m curious: what does this generate? (I use Sublime Text and it seems to generate everything I need automatically – e.g. a list of symbols for lookup. I’m curious if I’m missing something.)


(Jim Bosch) #5

For C++, it would be generating a config file that includes the complete include path for all setup packages. This might be unnecessary for you if you either only care about your editor knowing about symbols from the package you’re working on, or if your workflow involves telling the editor about the full source tree (e.g. in lsstsw) rather than building against installed (e.g.) weeklies.

In Python, it’s creating a config file that propagates PATH, PYTHONPATH, LD_LIBRARY_PATH, and EUPS’s *_DIR variables to the editor without me having to start the editor from a shell with all of those set - that’s particularly relevant when doing remote editing over SSH (where what’s actually relevant is the editor server process one doesn’t normally start manually), but also something I find nice in general.


(Brian Van Klaveren) #6

I think this is the closest to a standard. See Also:

https://clang.llvm.org/docs/JSONCompilationDatabase.html
https://www.jetbrains.com/help/clion/compilation-database.html