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.
-
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.
-
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)
-
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.
-
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)
-
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”
-
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)
-
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.
-
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.
-
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)
-
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.
-
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)
-
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”
-
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)
-
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