I have some C++ source which includes the line:

#include <Eigen/Core>

The compilation fails at this line, with the error: (my source file names/paths redacted for brevity.)

In file included from ___.h:8,
                 from ___.cpp:1:
____.hpp:5:10: fatal error: Eigen/Core: No such file or directory
    5 | #include <Eigen/Core>
      |          ^~~~~~~~~~~~~~~~~~~
compilation terminated.

The strange thing is that building this from the command line (even using the Ninja file that CLion generated) works fine.

My CMakeLists.txt includes the following:

include_directories("/usr/local/include" "/usr/local/opt/llvm/include"
        "/usr/include/eigen3" "/usr/include/eigen3/unsupported"
        "include/" "include/minidnn" )

Most relevant are the two eigen-related paths. Under /usr/include/eigen3 is (I have triple checked) a folder called Eigen, within which is a file named Core. This is the reason that I believe this build system should work. As mentioned, this does work when not building through CLion.

To try and debug this, I added --verbose to the g++ flags. Here is the relresult:

ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/include-fixed/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/../../../../x86_64-unknown-linux-gnu/include"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/local/opt/llvm/include"
ignoring nonexistent directory "/usr/include/eigen3"
ignoring nonexistent directory "/usr/include/eigen3/unsupported"
#include "..." search starts here:
#include <...> search starts here:
 /home/garby/Documents/code/cpp/shared-memory-sgd/include
 /home/garby/Documents/code/cpp/shared-memory-sgd/include/minidnn
 /usr/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/../../../../include/c++/13.2.0
 /usr/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/../../../../include/c++/13.2.0/x86_64-unknown-linux-gnu
 /usr/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/../../../../include/c++/13.2.0/backward
 /usr/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/include
 /usr/lib/gcc/x86_64-unknown-linux-gnu/13.2.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
Compiler executable checksum: 783eab82059e8c1c7db8dfb100492c35
In file included from /home/garby/Documents/code/cpp/shared-memory-sgd/include/minidnn/NetworkExecutor.h:8,
                 from /home/garby/Documents/code/cpp/shared-memory-sgd/semisync.cpp:1:
/home/garby/Documents/code/cpp/shared-memory-sgd/include/minidnn/ParameterContainer.h:5:10: fatal error: Eigen/Core: No such file or directory
    5 | #include <Eigen/Core>
      |          ^~~~~~~~~~~~
compilation terminated.

This seems strange. Most of the directories that g++ is claiming are “nonexistant” are absolutely existant. For instance, /usr/local/include and /usr/include/eigen3 exist. The permissions on these files/directories also look acceptable:

drwxr-xr-x 1 root root 100 Feb  2  2022 /usr/include/eigen3/
drwxr-xr-x 1 root root 584 Feb  2  2022 /usr/include/eigen3/Eigen/
-rw-r--r-- 1 root root 12799 Feb  2  2022 /usr/include/eigen3/Eigen/Core

For completeness, here is the full command which is invoked by Ninja (under CLion) before it fails.

/usr/bin/g++  -I/usr/local/include -I/usr/local/opt/llvm/include -I/usr/include/eigen3 -I/
usr/include/eigen3/unsupported -I/home/garby/Documents/code/cpp/shared-memory-sgd/include 
-I/home/garby/Documents/code/cpp/shared-memory-sgd/include/minidnn -fopenmp -g --verbose 
-std=gnu++20 -fdiagnostics-color=always -MD -MT CMakeFiles/mininn.dir/semisync.cpp.o 
-MF CMakeFiles/mininn.dir/semisync.cpp.o.d -o CMakeFiles/mininn.dir/semisync.cpp.o 
-c /home/garby/Documents/code/cpp/shared-memory-sgd/semisync.cpp

If I run this command manually, from the terminal, that source file builds correctly(!) This, I believe, is the crux of the problem. CLion must be doing something strange when it comes to path resolution. Does it execute inside some kind of container?…

(While writing this, I discovered the answer. I’ll post the question anyway, and post the answer too, just in case anyone else comes across the same problem.)