AppFramework Improvements

From Nocturnal Initiative

Build Systems

Currently Insomniac makes exclusive use of Visual Studio as a build and development environment (for better or worse). It would be nice to support some compelling alternatives such as Code::Blocks: http://www.codeblocks.org/, Eclipse CDT: http://www.eclipse.org/cdt/, or others.

Our biggest showstopper for making this happen is code within the project that does not conform to the C++ Standard. Some items should be easy to rectify (like the inclusion of several keyword extensions in cl.exe like 'override' and 'abstract'), while in other cases we make use of unions whose members have constructors.

ToDo:

• Cull cl.exe-specific keywords
• Turn off compiler extensions in cl.exe (don't know if this will cause errors in unions or not)
• Start trying to build using gcc and Code::Blocks to resolve the remaining issues

Module Interdependency

Modules within the framework include and link each other pervasively. This is useful when consuming the entire framework, but can make consuming individual pieces difficult. At some point we want to support a compilation mode that minimizes the inter-dependencies between modules. For the modules that could be made to support this there would be two top level build configs: Monolithic and Modular.

Let take an example of how this would be implemented. Reflect currently depends on Console to log its activities. Within Reflect's API.h we should have a preprocessor macro REFLECT_CONSUME_CONSOLE that governs whether or not Reflect should consume Console::Print() or printf():

API.h

#ifdef REFLECT_MONOLITHIC
# define REFLECT_CONSUME_CONSOLE
# define REFLECT_CONSUME_COMMON
#endif

Archive.cpp

#ifdef REFLECT_CONSUME_CONSOLE
 Console::Error( "Something bad happened\n" );
#else
 fprintf( STDERR, "Something bad happened\n" );
#endif

Dynamic vs. Static Libraries

Since Insomniac still has some .NET dependencies we rely exclusively on DLL configurations of our libraries that make use of any sort of global data. This is becoming less of a priority since we have stopped developing for .NET. At some point we need to have a static configuration that we can build our libraries with.

This is simple in most cases (it just means we double the number of project configurations). However an exception has to be made with Reflect. Reflect makes use of known extry points in PE files (both DLL and EXE files) in order to register defined reflection types at run time. So long as those types are defined in a DLL the types are one to one with DLLs that define them. This is not true of static libraries that may define reflection types, so we will need some way of handling two different DLL or EXE files that link against the same static library that exposes reflection types.