Code::Blocks Forums
User forums => Using Code::Blocks => Topic started by: bootstrap on July 16, 2011, 12:03:55 pm
-
I probably made a huge mistake when I started developing a large application, and now is time to pay for that mistake. Please help me extract myself from this mess with the least pain, if such is even possible.
background
I developed a 3D simulation/graphics/game engine on Linux and Windoze in C (actually compiled as a C++ program but has no classes, templates, other wacko C++ features). Being a bonehead at the time, I developed the Linux version in CodeBlocks and the Windoze version in VisualStudio2005. The exact same set of files compile on both Linux/CodeBlocks and Windoze/VisualStudio2005 to create executables that work.
The files contain about 100 instances of #ifdef LINUX and #ifdef WINDOZE around sections of code, mostly to deal with calling XWindows/xlib functions versus Win32 API functions to create and manage displays/windows/queues. Otherwise I generally call standard C library functions that exist on both platforms with a few exceptions.
The underlying graphics is handled via GLEW, GLX and OpenGL v3.20 or higher (plus GLSL shaders of course).
current situation
Now I need to compile executables on Windoze with CodeBlocks. This leaves me confused about a few issues.
#1: My first realization was that I needed a new pair of preprocessor symbols, which I call TOOLSGNU and TOOLSVS to distinguish compiler and assembler syntax differences that exist in the GNU toolset versus the VisualStudio toolset. I had to go back to all instances of #ifdef LINUX and #ifdef WINDOZE and decide whether each should remain as is, or should be replaced by TOOLSGNU or TOOLSVS. This was not previously necessary because all Linux implementation code was compiled and assembled by GNU tools, and all Windoze implementation code was compiled and assembled by VisualStudio2005 tools. However, developing on Windoze with CodeBlocks breaks that convenient oversimplification and requires these additional symbols.
#2: My next question is, how much code needs to exist in 2 flavors (GNU versus VS)? For example, right now I have separate source code for a rather large number of printf()-like function calls. I had to do this because several of the format specifications are different in GCC versus VCC libraries (especially for 64-bit integers and wide characters (which are 32-bits in the GCC libraries and 16-bits in the VCC libraries). Plus a few other differences exist between functions in the standard C libraries on these platforms. So my question here is this. Do the GNU standard C libraries exist in a typical CodeBlocks environment. Are the GNU style variants of the printf()-like functions available... or should I still be calling the VisualStudio function libraries? I am a bit skeptical that I can have both due to name collision, but also I probably need the VisualStudio function libraries in order to deal with 16-bit wide strings that are passed to Windoze API functions that I call. So my guess is, GNU function libraries are not practical in my situation. Is this correct?
#3: I'm getting a whole slew of errors that seem to indicate this whole plan is inherently flawed. For example, the types that GCC understands are NOT the types that win32 API .h files understand. Therefore, I'm getting the impression this whole idea of compiling win32 applications with CodeBlocks+GNU-tools doesn't work! Is this correct? If so, is it possible to make CodeBlocks compile with the VisualStudio tools when I'm developing on Windoze? Or are there just too many inconsistencies to make this work in any practical manner?
The bottom line seems to be, I need general advice as to whether this is even possible... or practical... or worth the effort involved. Given what I have working (see "background" at the top), what's my best bet? I hate to require people have VisualStudio products to further develop this code with me, but... maybe that's what should happen?
-
AFAIK, CB can use VS toolchain, but I can't tell for sure how good it works. It is sad that you didn't start with a cross-platform toolkit (your own or 3rd party) that would have taken care about IO, unicode/wide strings, and all of that kind of stuff, but it may be possible to rewrite critical pieces of code to allow compilation with both VS and GNU (MinGW) tools. And CodeBlocks is a great IDE, it can import VS projects, but you have to deal with underlying toolchain, not CB itself.
Considering numbered questions... IMO:
1) Yes, you may need to define macros for both OS and toolchain to wrap platform-specific code into cross-platform envelope. However, it might be easier to put these pieces of code into one library and clean all of other code from potential problems.
2) See how Qt, wxWidgets and other cross-platform toolkits got these problems solved. Differences between platforms are limited to low-level stuff which is closed in the cellar.
3) Try to attach VS toolchain to CB, it should work I think. But it will be a temporary solution anyway.