Is the idea just that we’d separate the ProjectInfo into its own standalone header? If so, I don’t see any major drawbacks of that approach, so I’ll see how feasible this is to implement.
That being said, I think it’s possible to do a bit better than the existing
ProjectInfo design, especially if you’re using CMake. You might want to roll your own approach, even if we end up making the suggested change.
The current design will force you to recompile any TU which includes the ProjectInfo definitions, whenever the definitions change. However, we can shuffle things around a bit, so that your header just includes the data declarations (we’ll use a struct while we’re at it, we don’t need to use argument dependent lookup here):
static const char* const projectName;
static const char* const companyName;
static const char* const versionString;
static const int versionNumber;
Then, we can use CMake’s file configuration tools to generate a matching .cpp. This way, if any of the project info changes, we will only need to recompile this single tiny .cpp.
Granted this is a bit academic because most of the info is provided in preprocessor definitions, which will also force your project to rebuild completely… but this approach will give you faster incremental builds in parts of your codebase which don’t depend on JUCE and its preprocessor flags, but do depend on the project info.
Also, managing this yourself will allow you to extend the struct with other relevant information, such as the current git hash of the repository, the date of the build, and so on.