Adding `cmake` option `-DEXPORT_COMPILE_COMMANDS=ON`

[syf1913]

Given that some users use LSP (Language Server Protocol) for reading, navigating, and debugging source code, when using CMake to build IBAMR and its dependencies, could consider outputting compile information , compile_commands.json? Specifically, when using the cmake command, adding the option -DEXPORT_COMPILE_COMMANDS=ON. This is very important for LSP, especially for clangd.

[syf1913]

Maybe add -DEXPORT_COMPILE_COMMANDS=ON into line 714 of autoibamr.sh.

[boyceg]

@drwells it would be good to give this as an option --- maybe even default it to enabled --- although, I am not sure how clangd will interpret code that is compiled multiple times within the library but with different values of NDIM.

@syf1913, I also have gotten good results using simple compile_flags.txt files. Here is a sample one:

-DDEBUG
-DHAVE_CONFIG_H
-DNDIM=3
-I/Users/boyceg/code/IBAMR/include
-I/Users/boyceg/code/IBAMR/ibtk/include
-I/Users/boyceg/code/IBAMR/ibtk/contrib/muparser/include
-I/Users/boyceg/code/ibamr-objs-dbg
-I/Users/boyceg/code/ibamr-objs-dbg/config
-I/Users/boyceg/code/ibamr-objs-dbg/ibtk
-I/Users/boyceg/code/ibamr-objs-dbg/ibtk/config
-I/Users/boyceg/sfw/libmesh/darwin-clang-dbg
-I/Users/boyceg/sfw/libmesh/darwin-clang-dbg/include
-I/Users/boyceg/sfw/petsc/release/include
-I/Users/boyceg/sfw/petsc/release/darwin-dbg/include
-I/Users/boyceg/sfw/samrai/2.4.4/darwin-clang-dbg
-I/Users/boyceg/sfw/samrai/2.4.4/darwin-clang-dbg/include
-I/Users/boyceg/sfw/silo/4.11/include
-I/opt/homebrew/Cellar/llvm/14.0.6_1/include
-I/opt/homebrew/Cellar/llvm/14.0.6_1/include/c++/v1
-I/opt/homebrew/include
-Wall
-Wextra
-std=c++17
-xc++

Just put this in the top-level IBAMR source directory. You would need to update the directories to point to the correct locations for your own installation.

There is some (out of date) information on setting this up here: https://github.com/IBAMR/sublime-settings.

[drwells]

Before we add anything I want to make sure I understand this workflow.

compile_commands.json lists compilation commands used to build a project. It doesn't make sense to install this file since it only contains information about how to compile the already-compiled project. To the best of my knowledge, no major cmake-based project installs this file for that reason. How do you plan on using this file?

[boyceg]

I think that the details depend on the programming environment, but I think that you would basically put this in the application code base to facilitate autocompletion for IBAMR's API.

[drwells]

In that case the downstream project should just export its own compilation commands - making our own available won't help.

[boyceg]

Why would it not help?

[syf1913]

I think that the details depend on the programming environment, but I think that you would basically put this in the application code base to facilitate autocompletion for IBAMR's API.

Indeed, it depends on the programming environment. For me, I use VSCode + clangd (LSP). When compiling source code, generating compile_commands.json, clangd relies on this file to parse the source code, thereby providing more accurate code navigation, code completion, and many other useful features. It's not just clangd; other LSP applications might also depend on this compilation information file.

[syf1913]

In that case the downstream project should just export its own compilation commands - making our own available won't help.

When I add IBAMR to my project, I not only need to debug my own code but also need to understand how the IBAMR source code works. Therefore, as I mentioned above, with the compilation information of the IBAMR source code, the LSP can help me complete and debug the code more efficiently, both for the IBAMR and my project source code. : )

[syf1913]

So, just consider it; maybe it's a good option. If you don't like it, just ignore it—it's entirely up to you. Thank you for your response, much appreciated. @drwells @boyceg : ）

[drwells]

It isn't so much that I want to add or ignore this feature as, to the best of my knowledge, this isn't going to work the way you think it will. The information in that file is, e.g.,

  "directory": "/ibamr/build-debug",
  "command": "/usr/bin/c++ -I/ibamr/include -I/ibamr/build-debug/ibtk/include -I/opt/petsc/linux-c-opt/include
-I/usr/include/hypre -I/usr/include/superlu -I/Applications/samrai-2.4.4.g/include
-I/ibamr/ibtk/include -isystem /usr/include/eigen3 -g -O1 -Wall -Wpedantic -Wpointer-arith
-Wsign-compare -Wswitch -Wsynth -Wwrite-strings -Wcast-align -Wsized-deallocation -Wvla
-Wpacked -Wunused-variable -Wlogical-op -Wnon-virtual-dtor -pedantic -Wextra -Warray-bounds
-Whsa -Wsubobject-linkage -Wno-deprecated-copy -Wformat -Wmissing-include-dirs
-Wmisleading-indentation -fno-omit-frame-pointer -Woverloaded-virtual
-Wmultistatement-macros -Wstringop-truncation -Wrestrict -Wdangling-else
-Wmaybe-uninitialized -Wplacement-new=0 -fdiagnostics-show-template-tree
-fuse-ld=mold -fPIE -DNDIM=2
-o examples/wave_tank/ex1/CMakeFiles/wave_tank-ex1.dir/example.cpp.o
-c /ibamr/examples/wave_tank/ex1/example.cpp",
  "file": "/ibamr/examples/wave_tank/ex1/example.cpp",
  "output": "examples/wave_tank/ex1/CMakeFiles/wave_tank-ex1.dir/example.cpp.o"

This information is useless in user projects since you are not compiling these files yourself.

What happens when you set up your own project with -DEXPORT_COMPILE_COMMANDS=ON?

[boyceg]

I think that it is still useful in a project that is linking to the library, particularly if that project itself doesn't know how to generate compile_commands.json --- I am imaging a small application that doesn't have its own build system infrastructure.

How hard would it be to set up a branch that @syf1913 could use to try it out? (I also may have some time this week to try this out myself.)

I'll also note again that one alternative that is very easy but requires knowing where various packages are installed is to use compile_flags.txt as described above. That seems to work great with clangd.

[syf1913]

In my own project demo 1, it looks like this:

[
{
  "directory": "/home/syfan/temp/demo-1/build",
  "command": "/usr/bin/c++  -isystem /home/syfan/sfw/ibamr/0.13.0/0.13.0-opt/include -isystem /home/syfan/sfw/ibamr/0.13.0/0.13.0-opt/include/contrib/muparser -isystem /home/syfan/sfw/linux/libmesh/1.6.2/1.6.2-opt/include -isystem /home/syfan/sfw/petsc/3.17.5/include -isystem /home/syfan/sfw/petsc/3.17.5/linux-opt/include -isystem /usr/include/tirpc -isystem /home/syfan/sfw/samrai/2.4.4/linux-g++-opt/include -isystem /usr/lib/x86_64-linux-gnu/hdf5/serial/include -isystem /usr/lib/x86_64-linux-gnu/openmpi/include -isystem /usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -isystem /home/syfan/sfw/linux/boost/1.66.0/include -isystem /usr/include/eigen3 -march=native -O3 -DNDIM=2 -o CMakeFiles/main2d.dir/example.cpp.o -c /home/syfan/temp/demo-1/example.cpp",
  "file": "/home/syfan/temp/demo-1/example.cpp"
}
]

with this file, the LSP can help me directly navigate from my project source code to the IBAMR source code. Also, if IBAMR generates this file during compilation, the LSP will also help me navigate within the IBAMR source code. This makes the process very smooth and efficient. As for how clangd works with compile_commands.json, unfortunately, I really don't know :( .

[syf1913]

I think that it is still useful in a project that is linking to the library, particularly if that project itself doesn't know how to generate compile_commands.json --- I am imaging a small application that doesn't have its own build system infrastructure.

How hard would it be to set up a branch that @syf1913 could use to try it out? (I also may have some time this week to try this out myself.)

I'll also note again that one alternative that is very easy but requires knowing where various packages are installed is to use compile_flags.txt as described above. That seems to work great with clangd.

Take it easy, : ), thank you so much for saying that. Yeah, I will give it compile_flags.txt a try. Thanks again.

[drwells]

Are there any examples of other projects with export their compilation commands database? I don't think this is ever a useful thing to do for the reasons I outlined above (and no editors support this kind of multi-project configuration).

If no-one is going to use this in practice then lets close this.

[boyceg]

It seems like it would at least be useful for any IBAMR developers who use autoibamr...?