Fix CMakeLists.txt

[madmann91]

• Use modern CMake target_link_libraries for SDL2
• Fix bug where gitsha1.c was never compiled

[vkoskiv]

I forgot to mention - In addition to the cmake build system, I also use Xcode. (the .xcodeproj file in the tree is for this) I've configured it to assume relative paths, so your change to githsha1.c.in there breaks that assumption.

[madmann91]

Using relative paths in generated files (that live in the build directory) will break any out-of-source build since the paths will not be the same as the source directory. Therefore, I have added the src folder in the include directories of the project, which handles that. The cleanest solution to allow out-of-source builds is to use relative directories with respect to the src base directory, or no relative path at all if the file is in the same directory (e.g. it would be fine to write #include "gitsha1.h" if it was from the same directory where gitsha1.h lives). An alternative to that is to add all possible subfolders of src in the include directories of the project, which I do not recommend as it would potentially introduce conflicts if you have files with the same name in different directories.

[madmann91]

Note that in your case if you only need the utils directory in the include path then you can just add it and change back the #include "utils/gitsha1.h" into a #include "utils/gitsha1.h". In any case CMake should take care of that when generating XCode project files, so I don't understand why you have that problem to start with. I would need to get more info to debug that. Can you post the output of the build command, with the full build commands? Normally CMake adds the src path so a -I..../src should be present.

[vkoskiv]

I'm not using an .xcodeproj generated by cmake, I'm using one that I maintain myself and include in the source tree. I did try autogenerating it with cmake a long time ago, but the resulting project was really poorly structured, and I didn't look into it beyond that at the time. What's the motivation for deviating from relative paths in the case of gitsha1.h?

[madmann91]

Well there are in general two robust ways to give include paths, which can be combined if required:

• Using the full path relative to the project include directory (e.g. if the source/include directories of the project are proj/src and proj/include then to include the file proj/include/math/analysis/complex.h one would type #include "math/analysis/complex.h", regardless of the position of the including file),
• Using the name of the file to include directly if the included file is in the same directory as the including file. This is not as robust, as things might behave in a strange way if the file is moved into another directory (this is currently what you do).

The problem is that, when including gitsha1.h from gitsha1.c, the paths are not guaranteed to be the same. Indeed, for an out-of-source build, gitsha1.c is in build/src/utils and therefore the include with just the path gitsha1.h doesn't work. For it to work, it is necessary to do either of those things:

• Change the include path to the first strategy for that file only, which is what this commit is doing, or
• Add the include directory src/utils to the include path. That is not as good, as it will mean that it becomes possible to include files that are in utils/ without the utils/ prefix, from anywhere in the source tree.