Unify and specify the types of special-purpose C++ files

[sebproell]

Originally based on this issue from Gitlab

Description

We use different special extensions to signify special purpose files, e.g., _fwd.hpp, _templates.hpp, .fwd.hpp.

Possible Solution and Definition of Done

• [x] Gather all of them and make sure there is only one way to do things:
  • [x] .hpp is used for header files (the ones that get included).
  • [x] .cpp is used for C++ source files (the ones that get compiled).
  • [x] _fwd.hpp files typically contain explicit template instantiations. .inst.hpp is likely a better name.
  • [x] .fwd.hpp is used for forward declarations.
  • [x] .templates.hpp is used for headers with separate template definitions (needs to change from _templates.hpp). This file makes sense, when templated code is really expensive to include alongside the normal .hpp, e.g. when templated functions use expensive include such as Sacado.
  • [x] .<ext>.in is used for files that are configured by CMake into the build tree as .<ext>
• [ ] Document it.
• [x] Update cmake.

Interested Parties

@knarfnitram (I adapted this slightly)

[sebproell]

Also related to the question of how we forward declare external symbols, see https://gitlab.lrz.de/baci/baci/-/issues/1346.

[isteinbrecher]

We also have some .cpp files that are automatically generated, e.g., https://github.com/4C-multiphysics/4C/tree/main/src/shell_kl_nurbs/src , I think it would make sense to add something like _autogen.cpp to distinguish these files from "normal" .cpp files.

[sebproell]

@isteinbrecher What would be the benefit of having this _autogen.cpp extension? The extensions I listed above are all relevant for the build system (and to some extent to developers). I guess this _autogen would notify devleopers that they are modifying a file that they should rather generate? The problem I see here is that it is not clear how to generate them. Currently the generating scripts are more for documentation and are not actually used and tested.

[isteinbrecher]

Yes the main feature would be that it is clear that functional changes should not be made to such files, but rather to the source file.

However, you are right, if we don’t test the generating script such a postfix for the name might be overkill. At least for AceGen scripts I don’t see a way to test this in the near future, so I am fine with just manually adding this to the file name.