-
Notifications
You must be signed in to change notification settings - Fork 66
Description
There are a few headers like stinger_defs.h.in that are generated at configure time. So the header file stinger_defs.h is actually a generated build artifact that doesn't belong in the source directory. Source files still need to know where it is. So the current build system copies the file to an include subdirectory in the build dir and adds this to the includes.
For better or for worse, ALL headers are currently handled this way. They are copied to the build directory and included from there. This has several consequences, most of which I consider negatives.
- The include path is not the same as the location of the file in the source tree. For example,
pagerank.his located inlib/stinger_alg/inc/, but in the build directory it isinclude/stinger_alg/pagerank.h - When using "goto definition" in an IDE, the IDE will locate definitions in the build directory copy of the header, but edits to this copy will be lost before the next build.
- CMake loses the ability to track dependencies between libraries. If
stinger_algneeds a header fromstinger_net(but not a link dependency) we have to ensure that the headers get copied beforestinger_algis built or the build will fail. CMake will figure out the dependency DAG with linking, but it assumes headers will just "be there" unless you explicitly tell it that you depend on a header file that doesn't exist yet
The only advantage I see is in allowing libraries like stinger_core to control what their public interface looks like, possibly not publishing all their headers. But this would be better handled by an "install" target anyways.
Instead, all headers should simply be included from the source directory. A custom solution can be implemented for the few headers that need to be generated during the build.