You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.h is located in lib/stinger_alg/inc/, but in the build directory it is include/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_alg needs a header from stinger_net (but not a link dependency) we have to ensure that the headers get copied before stinger_alg is 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.
The text was updated successfully, but these errors were encountered:
Yes I agree that all of these things are negatives. Perhaps a more permanent solution is to reduce the number of things that are compile time constants that need to be generated. Is there an easy way to find out what is preventing that?
There are a few headers like
stinger_defs.h.in
that are generated at configure time. So the header filestinger_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.
pagerank.h
is located inlib/stinger_alg/inc/
, but in the build directory it isinclude/stinger_alg/pagerank.h
stinger_alg
needs a header fromstinger_net
(but not a link dependency) we have to ensure that the headers get copied beforestinger_alg
is 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 yetThe 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.
The text was updated successfully, but these errors were encountered: