I've been doing some thinking about how to improve the SDK, and I've come to a few conclusions.
First of all, We need to set some kind of standard build environment. All too frequently, people send me code to look at, or test, or debug, and it won't build because it can't find the SDK headers. I'm sure other people must have run into this too, where they get a chunck of code, and they have to modify it to get it to work. Now with that said, I can understand someone sending code that won't compile for help specifically with why it won't compile, but we should do something about standard header files and libraries so as to not continually waste time on these issues (which are never what they're asking about anyways).
I propose the following setup, relative to some arbitrary install folder:
API/Outpost2DLL/
API/OP2Helper/
API/Other.../ (HFL, IUnit, Forced Exports, etc.)
Template/Blank/
Template/Blank-Comments/
Level/ProjectName1/
Level/ProjectName2/
...
There are a few reasons for this idea. One is that it seperates out the common API code from the level code. I especially like this when multiple APIs are installed, since it lets you see exactly which APIs are installed, and quickly find their code. Without this separation, it's too easy to miss a folder you're looking for. By putting the level code at a known location relative to the API, you can move the root folder around without breaking anything. Also, by putting the level code in some sort of level subfolder, you can seperate out different types of levels if you needed, and they'd all still be at the required (relative) level. Perhaps you collect a lot of code from other people, and want to keep it seperate from yours. Then you can have a folder such as LevelOther/ to stick those projects in. The Template/ folder listed above is another instance of this idea. Perhaps we could also have an Example/ folder someday.
Now, by keeping the folders at the same relative locations, we can set relative include paths for headers and libraries. For Visual C++ 6.0, this can be set under: Project -> Settings -> C++ -> Preprocessor -> Additional include directories, (for header files), and under: Project -> Settings -> Link -> Input -> Additional library path, (for .lib files). This of course can be done in blank template missions, so that if someone copies the blank template project folder to start a new project, these settings will already be setup for them. There is of course ways to do this in CodeBlocks, or newer compiler versions, or even from a command line build system if required (using the /I and /libpath command line options).
Another thing that would be helpful, is to perhaps merge the other APIs people have been using into a standard download package. That way they can just unzip the package at an arbitrary location, and everything will be installed, and at the same (relative) place that everyone else has it at. Then we won't run into these compiling problems when exchanging code using these other libraries.
There is a slight issue that still needs to be solved though. If we add new APIs, with their own header and libraries, it could potentially require adding more include folders for both headers and libraries. I suspect many people won't know to adjust the project settings, or where within that mass of options to even look, so I'd like a system that avoids having to change project settings. We could handle this by placing master header files in one known folder, and a similar setup for libraries. This means having a common folder that shares files from all API projects. We could instead reference headers in the code using a relative offset from some known location (a bit messy, but fully separates the projects). This might look like: #include "Outpost2DLL\Outpost2DLL.h", where the API/ folder is set as an addition include path. There's also the issue of library files. What we could do, is set the build output location for the static libraries to be in some known folder (using a relative path to escape the project folder), rather than in a Release folder. By having a common lib and a common master header folder, or using relative include paths, we can avoid adjusting project options.
I'm also thinking APIs should probably be distributed as static libraries if possible. That should avoid DLL versioning problems, such as the one posted to the forums recently. Although, I'm not so much against DLL libraries, as just adding source files to the current project, like how OP2Helper was traditionally used. I really think a static library project makes more sense here, as that's how it's being used. We can also set levels to depend on a static library project, so the static library is built, or rebuilt if it doesn't exist or changes have been made.
I'm also noticing people making changes to the standard libraries themselves. I can understand this, as they are often somewhat unfinished, and we can't expect people to wait around for a new release that may or may not come, and probably won't come soon. On the one hand, this can be a problem if header files diverge, because again, we'll have compiling issues when people share code. But I would like to encourage people to make these changes and improve those APIs. However, to avoid future problems and duplicating work, we need some way to distribute these changes to other people. I'm thinking SVN could be a good solution for this, although that would require people have a client (such as TortoiseSVN) installed, and also have write/commit access to the repository. It would also require all the shared code to be stored in the SVN. Currently HFL is not in there (hey BlackBox, would you mind if we put your code in the SVN?), and neither is Eddy's IUnit, which I don't think he released the source to, (Eddy, how about you?).
