views:

124

answers:

2

I have a game playing engine written in C++. I have my own "development" GUI. The program is for sale in Japan and I have a Japanese publisher that has written an commercial GUI to join up with my game playing engine. We have had this arrangement for many years. Both my engine and his GUI are large, complex and undergo regular changes between releases. When my publisher wants a new version I will send him my source files which he then compiles along with his GUI, and his GUI will call a set of prearranged functions within my engine. It seems that every time we go through this process we always get tripped up by a compiler flag or two being different at his end than mine. This would be a very small problem if we both spoke the same language and were in the same time zone, but as we don't it seems that even the smallest issue can cause major headaches and delays.

Someone has suggested that if I sent him a library rather than the sources then this would reduce the chance of errors, whilst someone else said that I should send him the project files.... I'm not so sure of the pro's and con's of either.

Does anyone have any tips or suggestions to minimize the risk of glitches in this process. Is there any way I could make a run-time/compile-time check to make sure all the compile and link options are as expected?

EDIT: Just noticed this question about recording the compiler flags in GCC. It seems that GNU allows this. Is there an equivalent command for visual studio?

+1  A: 

Separate the GUI from the engine as much as possible. Ideally the GUI should sit in a separate library, and only that library should be recompiled if the GUI is switched.

A good, and widely used solution is to separate your GUI using a scripting language, Lua is often used for that purpose.

Under Windows, the perfect solution would be to split the GUI in such a way, that a substitution of a dll would change the GUI itself. See OGRE, for examples of using dll's to provide modular subsystems.

Kornel Kisielewicz
+2  A: 

I would say it's actually somewhat surprising how sensitive all this code is to compiler settings. Do you know if your publisher in Japan compiles your code into a library, or directly compiles it into the main GUI? They certainly should not compile the two in the same project in Visual Studio if they require different compiler flags.

If this is C++, you can use boost's static assert to ensure that certain things are set, and you should probably also put a few #error macros in places if things are not set.

Having said that, I would send them a DLL and header files. This should work regardless of how they set their compiler flags.

Edit: in addition, depending on what your game is you would probably be well advised to replace deep calls into your engine with a protocol that you can define using JSON, XML, ASN.1, or your own grammar - if your game does not have hardcore realtime GUI requirements, that is. In that case, the interface becomes trivial and will be hard to break with things like wrong linking flags.

xcut
the sensitivity to compiler flags come about through size, complexity, optimizations and age. I work on the program full time and 99.999% of what I write is independent of flags, but once every few years I do something that makes the program sensitive to one flag or another... 25 years later... and the program is now very sensitive to many flags.
Mick
The DLL idea sounds promising... I've never made a DLL before, so I need to investigate further...
Mick
Creating DLLs used to be quite complex, but it's not anymore really. If your project is C++, change the Configuration Type in the General tab of the project to DLL. In the C++/Code Generation tab, set the runtime to Multithreaded DLL (that's the Microsoft runtime, not yours). This advice should explain the rest: http://www.codeproject.com/KB/cpp/howto_export_cpp_classes.aspx
xcut