Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
enum reorganization or merging project into Outpost2DLL #22
As discussed in PR #20, the organization of NonExportedEnums was currently considered sub-optimal. Proposed solutions were:
If OP2Helper is included in Outpost2DLL's project file it would:
If OP2Helper is not included in Outpost2DLL, I suppose the opposite would just be true.
I think I would be okay supporting either solution.
I believe the linker does a pretty good job of stripping out unused code. If OP2Helper code becomes part of the Outpost2DLL project, but isn't used, it likely won't add to the output executable size.
It probably would be a good idea to spilt the enum file into multiple files. This is true regardless of which project they end up being in.
If merging projects, and namespace pollution is a big deal, we could still have different top level header files for the 3 sections. There would be "Outpost2DLL.h" (game/), "Outpost2App.h" (shell/), and "OP2Helper.h" (we haven't yet discussed a folder name for this code if it is merged).
Related to the above, as there is some discrepancy between the header name and the folder they represent, we might consider updating names at some point. For renamed headers, we could offer compatibility shim header files to keep old code compiling, with perhaps a deprecation warning in them.
As OP2Helper code must necessarily include Outpost2DLL code, we could explicitly specify that including OP2Helper also includes all the Outpost2DLL names (that's already how things work). That would be a path for reducing header includes, while getting access to both projects.
Merging would make Outpost2DLL a proper static library, rather than a quasi static library which just contains the already pre-compiled Outpost2DLL.lib file. It would however end up having two static libraries. One being compiled and provided, and one being imported. Related, we probably should have named Outpsot2DLL.lib as simply Outpost2.lib. This is an import library for the project, not the compiled export library, so it's name probably shouldn't exactly match the project name. It is effectively the output of the Outpost2.exe project, which we don't have source code for. The header files from Outpost2DLL are effectively the import headers that we expect the Outpost2.exe project to have provided. You might think of the Outpost2DLL headers and static library as a binary release of the Outpost2.exe project. Sorry if that all gets a bit muddy and hard to follow.
Based on the last comment, I think @DanRStevens is in favor of moving OP2Helper into Outpost2DLL. I generally agree with the made comments.
To condense it:
Also, I am assuming it is possible, but I don't know how to merge two repository histories into one. IE keep OP2Helper's history when it is pushed inside of Outpost2DLL.
This history will be an interesting problem. It should be possible, since I know the Git model supports independent branches. GitHub uses that for the GitHub Pages feature. I'm not sure of the specifics though.
I believe BlackBox or Arklon were once talking about merging projects. I don't remember for certain though, or know quite what they had in mind. For a change this big, we should probably consult other people.
The shim comment was in case we want to rename Outpost2DLL.h, Outpost2App.h, or OP2Helper.h. That is, we can rename the top level header includes with a compatibility shim that just issues a deprecation warning, and then includes the new top-level header name. Old code would still compile, but with a warning.
We would need to settle on a folder structure. It would be nice if we could have folder names that matched up with top-level header names. I don't have anything satisfying at this time. I was thinking of "opu/" for our custom code such as OP2Helper, but that's way too vague and generic, particularly considering we have other projects that may or may not be merged at a later date.
We might need to sit on this idea for a little while.