Pointers for cross development? + how do YOU develop cross-platform?

I am planning to develop in Linux, then, once a stable version of my
app
exists in Linux, port it to Windows/MingW.

This is my setup, and it really works. I develop in Linux (no need to
explain why) and then build Windows versions. They are rock-solid,
enough
to [try to] sell them as shareware without any problems
(http://www.mrio-software.com). I recently ported my games to Mac, in
about
4 hours of work. Having portability in mind from the beginning does pay.

  1. Use only cross-platform libraries. I use SDL and ZLIB. If you must
    use something
    non-portable, make an abstraction layer (ie a IRenderDriver with a
    Direct3D and an
    OpenGL implementation). Yes, you can use Direct3D with SDL - I wrote a
    small HOWTO
    that Sam should put in the site sometime.

  2. Use one compiler, preferably the same version. I use g++ 3.3. An
    unsigned long time
    ago I compiled my libraries with g++ in Linux and VC++6 in Windows, but
    VC++ turned
    out to be too braindead for the way I used C++ templates (nothing
    complicated, it had
    trouble casting smart pointers and with some overloaded operators)

  3. Make a utility library where you encapsulate everything that is or
    could
    be system dependent. I have a library with Stream classes, compression
    classes, resources, and so on. There’s a delicate balance between
    "enough
    self contained" and the “not invented here syndrome”, however.

  4. Build system : a set of custom Python scripts, as “smarter
    makefiles”. I have
    scripts for building a binary from its sources (calculating the
    dependencies using
    a gcc flag which I don’t remember now), building images from specs (for
    example,
    it can take a 32 bit PNG and spit an 8-bit color BMP and a 4-bit alpha
    channel BMP),
    to build resource files,… finally creating a “distribution” directory
    with a
    symlink to the binary and symlinks with resource files and dynamic
    libraries, for
    each “configuration” (see below)

  5. Everything system-dependent (ie some tool names, paths, extensions)
    is stored
    in a per-configuration file that looks like a configuration file but is
    actually
    Python code :

    OBJ_SUFFIX = ".obj"
    EXTRA_LINK_FLAGS = “-Wl,–subsystem,Windows”

  6. Making a complete build is as easy as “./build.py CONFIG=win32.full”
    (this
    includes build.conf.win32.full in the above format, and calls the
    recursive,
    specialized build.py scripts)

  7. NSIS (the Nullsoft installer) command line compiler runs just fine
    under WINE
    so you don’t need to boot even to make your windows installers!

Hope this helps!

--Gabriel

Ing. Gabriel Gambetta
ARTech - GeneXus Development Team
ggambett at artech.com.uy

I think this helps many people.
I would like to add one library you could think to add in your cross
platform base and this is physfs. It can take care of the file system
abstraction delivers transparent zip archiving and transparent file /
directory overlays.On Wednesday 17 March 2004 15:20, Gabriel Gambetta wrote:

I am planning to develop in Linux, then, once a stable version of
my

app

exists in Linux, port it to Windows/MingW.

This is my setup, and it really works. I develop in Linux (no need to
explain why) and then build Windows versions. They are rock-solid,
enough
to [try to] sell them as shareware without any problems
(http://www.mrio-software.com). I recently ported my games to Mac, in
about
4 hours of work. Having portability in mind from the beginning does
pay.

  1. Use only cross-platform libraries. I use SDL and ZLIB. If you must
    use something
    non-portable, make an abstraction layer (ie a IRenderDriver with a
    Direct3D and an
    OpenGL implementation). Yes, you can use Direct3D with SDL - I wrote
    a small HOWTO
    that Sam should put in the site sometime.

  2. Use one compiler, preferably the same version. I use g++ 3.3. An
    unsigned long time
    ago I compiled my libraries with g++ in Linux and VC++6 in Windows,
    but VC++ turned
    out to be too braindead for the way I used C++ templates (nothing
    complicated, it had
    trouble casting smart pointers and with some overloaded operators)

  3. Make a utility library where you encapsulate everything that is or
    could
    be system dependent. I have a library with Stream classes,
    compression classes, resources, and so on. There’s a delicate balance
    between “enough
    self contained” and the “not invented here syndrome”, however.

  4. Build system : a set of custom Python scripts, as “smarter
    makefiles”. I have
    scripts for building a binary from its sources (calculating the
    dependencies using
    a gcc flag which I don’t remember now), building images from specs
    (for example,
    it can take a 32 bit PNG and spit an 8-bit color BMP and a 4-bit
    alpha channel BMP),
    to build resource files,… finally creating a "distribution"
    directory with a
    symlink to the binary and symlinks with resource files and dynamic
    libraries, for
    each “configuration” (see below)

  5. Everything system-dependent (ie some tool names, paths,
    extensions) is stored
    in a per-configuration file that looks like a configuration file but
    is actually
    Python code :

OBJ_SUFFIX = ".obj"
EXTRA_LINK_FLAGS = “-Wl,–subsystem,Windows”

  1. Making a complete build is as easy as “./build.py
    CONFIG=win32.full” (this
    includes build.conf.win32.full in the above format, and calls the
    recursive,
    specialized build.py scripts)

  2. NSIS (the Nullsoft installer) command line compiler runs just fine
    under WINE
    so you don’t need to boot even to make your windows installers!

Hope this helps!

I think this helps many people.
I would like to add one library you could think to add in your cross
platform base and this is physfs. It can take care of the file system
abstraction delivers transparent zip archiving and transparent file /
directory overlays.

I’ll look into it. I have my equivalent classes but I don’t do
directories.
In the way I work, I don’t really need them, anyway.

Ing. Gabriel Gambetta
ARTech - GeneXus Development Team
ggambett at artech.com.uy