Monday, 30 May 2011

A working setup

I appear to have cracked getting Codeblocks to create code that will run on both a Linux environment and Windows. The same project can be used to generate an OSX version of the application, although has to be separately created on my macBook.

The only extra bit would be to get the code to cross-compile and run under OSX from within Linux (the cherry on my cupcake).

The OSX build
This will only work (for the moment) natively using codeblocks.

  • Add new build targets OSXDebug and OSXRelease based on the default Debug and Release setups.
  • Change the compiler and linker to include the -arch i386
  • In the post-build steps add the following

mkdir -p $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/MacOS/
/Developer/Tools/SetFile -t APPL $(TARGET_OUTPUT_FILE)
/Developer/Tools/Rez -d __DARWIN__ -t APPL Carbon.r -o $(TARGET_OUTPUT_FILE)
cp $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/MacOS/$(TARGET_OUTPUT_BASENAME)
/usr/local/bin/dylibbundler -od -b -x $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/MacOS/$(TARGET_OUTPUT_BASENAME) -d ./$(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/libs/

For Windows
Install the mingw cross-compiler
Download and compile a mingw windows version of the wxwidgets libraries. This took a while...

Go to Settings, Compiler and Debugger settings. Add a new compiler based on the gcc one. Change the toolchain executables to point to the mingw executables.

Add new build targets WinDebug and WinRelease.
Change the compiler to the mingw one.
Make sure you have included the .exe extension for output filename.
Change the wx-config to point to the version you have compiled.

Other foibles for the Windows cross-compile
Certain libraries may be needed for the executable to run on the windows machine.

In the post build steps, add the following
cp /usr/share/doc/mingw32-runtime/mingwm10.dll $(TARGET_OUTPUT_DIR)
cp /usr/local/i586-mingw32/lib/wxbase28_gcc_custom.dll $(TARGET_OUTPUT_DIR)
cp /usr/local/i586-mingw32/lib/wxmsw28_core_gcc_custom.dll $(TARGET_OUTPUT_DIR)
cp /usr/local/i586-mingw32/lib/libwx_base-2.8*a $(TARGET_OUTPUT_DIR)
cp /usr/local/i586-mingw32/lib/libwx_msw_core*a $(TARGET_OUTPUT_DIR)

What next?
  • Having the compiler automatically generate an install routine for the windows (mainly to put the dll's into the windows system folder)
  • Getting the Linux build to cross-compile for the OSX platform
  • Writing an application that works across all three platforms

I'm not sure which of the three would be the easiest...

Further frustrations and a brief moment of joy

After getting the OSX code to compile and execute using OSX (and the codeblocks/gcc combination), my next plan was to get the code to compile under Linux.

I had set up my code in a dropbox folder so I could access the same codebase across all my machines, and booted my laptop running Ubuntu 11.04.

Codeblocks started, the targets for Linux added to the project and hit 'build and run'. I sat back to watch... Screens full of error messages, top of the list was
error: invalid use of incomplete type ‘struct wxFrame’

After going round in circles, checking that the include files were present (which they were) and a few other dead ends I ended up removing and re-installing the wxwidgets libraries. It felt like a desperation move, and oddly it worked.

My code now compiled and executed as expected under Linux. Feeling brave, I started investigating getting the code to work cross-compiling for a Windows target.

Mingw libraries and utilities installed, a test program put together (another version of the infamous "Hello, World!" application) and a Hello World message box running on my Windows VM.

Getting codeblocks to use the cross-compiler wasn't difficult, a new compiler setup copied from the gcc version and changing the toolchain executables did the trick (the only bit I'm not sure about is the debugger, but when the code is compiling cleanly I'll run through that set of options).

The only gotcha was that a set of libraries are needed to have the code execute on Windows XP (I don't have other options to test at the moment - at least not while Lynn is using her computer).

Sunday, 29 May 2011

Back to making progress

Hopefully these won't be the famous last words type of progress...

In the OSX Debug and Release build options we need:
-arch i386 in the compiler and linker options

In the post compilation build add


mkdir -p $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/MacOS/

/Developer/Tools/SetFile -t APPL $(TARGET_OUTPUT_FILE)

/Developer/Tools/Rez -d __DARWIN__ -t APPL Carbon.r -o $(TARGET_OUTPUT_FILE)

cp $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/MacOS/$(TARGET_OUTPUT_BASENAME)

/usr/local/bin/dylibbundler -od -b -x $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/MacOS/$(TARGET_OUTPUT_BASENAME) -d ./$(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).app/Contents/libs/


The only thing that is (mildly) irritating is getting the cocoa application to execute when the ide is trying to run the code.


Next step: get the basic code to compile and execute on the Linux box, and following that cross-compiling for windows (not sure if there will be different variants for XP, Vista and 7 though). And after that? Creating a useful (or otherwise) application.

>About to switch machines. After tea (gammon with honey glaze mmmmm)>

Famous Last Words

In my last post in this enthralling series on getting a development enviroment that will produce code on OSX, Windows and Linux I said that the next step was to get the MDI code working using wxWidgets.
You probably can't hear the hollow laugh (followed by silent screams, as I am coding in Starbucks), and you might not be surprised that a repeat project build.... isn't working.

I need to backtrack and work out what has changed, and get the setup working properly again. It would also be nice to get the post build scripts working so that I don't need to hard code folder names into the project.

I'm going to persevere for today, but I need my dual monitor setup to get it working properly: that either means bringing the big screen with me, or coding at home.

If you listen carefully, you just might hear me scream later tonight.