Versioning: Conditionally including entire files

[MonsterDruide1]

Follow-up discussion to #162.

So far, we can use #if FEATURE_FLAG to conditionally include functions/tokens/..., but this is not enough.

Between different versions, new files were introduced or old files were deleted as well. Currently however, all of them are included with add_library(...) in CMakeLists.txt without further conditions.

How should we handle adding/removing entire files depending on the version?

Suggestion A: #ifdef the entire file.

Suggestion B:
Move add_compile_definitions(SEAD_VERSION=CMAKE_SEAD_VERSION) from the application into sead's CMakeLists.txt, with CMAKE_SEAD_VERSION being a CMake variable (=> set(CMAKE_SEAD_VERSION "SMO") in application). Then, conditionally include files using CMake conditions (if(CMAKE_SEAD_VERSION STREQUAL "SMO")).

Suggestion C:
Combine B with removing the entire seadVersion.h, and handle everything in a separate CMakeLists.txt-file, which adds more compile definitions depending on the selected version.

Suggestion D?
Please suggest other things if you have a different idea.

[leoetlino]

conditionally compiling the relevant files sounds like the best option to me. can we do it with feature flags rather than a single version string?

[MonsterDruide1]

According to my current overview, the following files need to be excluded from SMO:
GameConfig, MultiProcessMeterBar, NinAocFileDevice, NinSDFileDevice, PatternRumbleAddon, ProcessMeterBase, ReadWriteLock, Semaphore, SpinLock, Worker and WorkerMgr.

Even when grouping a few of them together, that would be quite a number of feature flags, no?

[MonsterDruide1]

@leoetlino What is your opinion here?

[leoetlino]

I still think feature flags make the most sense tbh. We don't need one per file - we can group Worker and WorkerMgr together for instance, RWLock/Semaphore are another obvious group, etc.

[MonsterDruide1]

Given that these differences are likely the result of different versions of sead used within each application, and therefore somewhat out-of-control for the application itself, I would avoid setting the feature groups within the application itself. I think the best option that matches our opinion would then be to have a separate CMakeVersions.txt or similar that first translates the SEAD_VERSION_SMO or similar into a bunch of feature flags, which are then used in the main CMakeLists.txt to conditionally include files.

This means that applications get a single flag to control their version of sead, and all version differences between different versions of sead are centrally maintained in a single repo, not scattered across the applications themselves - just like the existing #defines in seadVersion.h for maintaining smaller differences between versions.

@leoetlino Happy with that suggestion? Should we also try removing the existing seadVersion.h then, and put all those #defines as compiler flags into the new CMakeVersions.txt then?

(side note: I'm not sure if that would actually work with libraries like agl including sead again indirectly - experiments would be required to see if set(...) flags in CMake can be passed through)