A Basic Starting Point - How to handle .h.in files

Usage
1

Hi!

I started the tutorial and got a question about dynamic include files (.h.in to .h)
Step 1: A Basic Starting Point

How to handle code validation (IDE, Lint, Editor) if the file to be included doesn’t exist yet? Are there any good practices for dealing with this? I checked the entire tutorial and I didn’t find it!

Regards,
Marcelo Módolo

2

Files created by configure_file are already generated by CMake, not later during the build.
So they do exist before opening the IDE.

3

Hi Josef Angstenberger!

Thanks for the answer!

But in the tutorial, the include file is created in the build folder. And in the .cxx file it is indicated as local to the .cxx file.

Furthermore, I believe that it would be necessary to run the build command at each modification for the defines to be valid.

I downloaded the tutorial files and tested it with VIM and EMACS configured as “IDEs” for C/C++. In both cases, the errors reported by CLANG were that the include file could not be found and that the definitions (#define) were invalid.

If I ran the build command to create the include file (in the build folder), I would still have to copy it to the same folder where the .cxx file was.

I was wondering if during the software development cycle (especially a big one) having to run the build for every change to an include file wouldn’t be too much work.

Maybe there is some good practice in the solution layout that I don’t know about that can solve this cyclic dependency.

Regards,
Marcelo Módolo

4

If you generate a project file for an IDE supported by CMake, or if you use an IDE that can query CMake (e.g. via File API) the include paths used for compilation are configured automatically.
Just using an IDE or editor without further configuration is missing defines or include paths given to the compiler on command line. I think that’s your case.

The tutorial adds the binary dir as global include path (this is where the file is generated to):

target_include_directories(Tutorial PUBLIC
                           "${PROJECT_BINARY_DIR}"
                           )

So the compiler knows that path and you have to teach your IDE to also know this path.

And yes, if any file changes you have to call the build tool, because it knows what exactly needs to be rebuilt.

5

Hi Josef Angstenberger!

Thanks again!

I solved the problem as follows:

mkdir build
cd build
cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=1 ..
ln -s ~/playground/cmake/Step2/build/compile_commands.json ~/playground/cmake/Step2/

Starting EMACS from ~/playground/cmake/Step2 no longer has errors! clangd reads the compile_commands.json file and is able to find the include files. Even the “#defines” are functional.

Unfortunately SPACEVIM does not make use of compile_commands.json and thus, it is necessary to create a “.clang” file with the contents below (but this is not a cmake problem):

-std=gnu++11
-I./build

Thanks for your help and patience,
Marcelo Módolo