Tweet
Hi,
i have had a brief look at the source; for porting civctp2 (I'd like to concentrate on linux and perhaps on generic portability stuff), there is quite some work to be done.
So far i read about port wishes to linux and macos x in this forum.
I sorted by complexity of the problem (most complex problem first).
1. getting rid of COM:
COM is a proprietary component framework by microsoft used heavily within the source. It is unportable to other platforms than windows and COM-based applications are known to even cause heavy problems under wine (don't run, random crashes, etc.).
If we want to keep a component based architecture, a replacement for COM has to be found. These options apply:
a) another portable component framework with compatible licence
b) reducing to some sort of contract programming (note: we'd need rtti for dynamic_casts which reduces portability heavily)
c) using no component framework at all
For a) i just have heard of XPCOM and UNO so far. Licensing would need checking.
For b), we'd need some design; clean handling of references often is a problem.
For c) and plugin handling of the mapsgen, a simple solution would be an abstract class defining a plugins interfaces, where each plugins impl has a c creation function which creates a new instance of the implementation.
I hope we don't need a component framework or somebody has an alternative we may choose.
2. porting DirectX calls:
DirectX replacement by SDL has already be discussed. On windows, still DirectX would be needed, because SDL calls the host systems native functions.
3. porting sound calls:
As discussed, the miless calls would need to be ported to sdl and maybe openal.
4. porting system specific stuff:
a) First of all, shared libraries handling can get rather complex:
Using shared libraries across platforms.
Libtool provides solutions for most of these problems; within libtool ltdl provides is an interface which abstracts accessing shared libs from within your programs (both LGPL).
That way, linux, macos x and windows shared library handling would be adressed.
For cygwin, we may need dlltool, but i'm not sure about this.
b) Other system related stuff:
For supporting other platforms than linux and windows on x86 (e.g. ppc), using autoconf/automake would ease things a lot.
Both are under GPL. Distributing source of these generators is allowed under the licence of its input, too (i.e. the EULA).
This not only allows a much simplified Makefile handling, but also eases other system dependent stuff a lot (mainly handling conditioned system programming stuff and corresponding headers), though providing a unique configuration mechanism.
I could also work on this part.
See: GPL FAQ
Distributing configure scripts
Distributing Makefile.ins
A very good point to start:
Autobook
5. Writing portable c++ code:
There are several guides, but most of my links are outdated because i learned the part i wanted to know meanwhile.
Still a good point to start is:
Writing portable c++ code.
Ok., i'm not through the source completly, perhaps there's something i missed.
So far i don't know how the linux port progressed. I hope i get access to the modifications soon, so i can start at some point.
Ciao
Holger
i have had a brief look at the source; for porting civctp2 (I'd like to concentrate on linux and perhaps on generic portability stuff), there is quite some work to be done.
So far i read about port wishes to linux and macos x in this forum.
I sorted by complexity of the problem (most complex problem first).
1. getting rid of COM:
COM is a proprietary component framework by microsoft used heavily within the source. It is unportable to other platforms than windows and COM-based applications are known to even cause heavy problems under wine (don't run, random crashes, etc.).
If we want to keep a component based architecture, a replacement for COM has to be found. These options apply:
a) another portable component framework with compatible licence
b) reducing to some sort of contract programming (note: we'd need rtti for dynamic_casts which reduces portability heavily)
c) using no component framework at all
For a) i just have heard of XPCOM and UNO so far. Licensing would need checking.
For b), we'd need some design; clean handling of references often is a problem.
For c) and plugin handling of the mapsgen, a simple solution would be an abstract class defining a plugins interfaces, where each plugins impl has a c creation function which creates a new instance of the implementation.
I hope we don't need a component framework or somebody has an alternative we may choose.
2. porting DirectX calls:
DirectX replacement by SDL has already be discussed. On windows, still DirectX would be needed, because SDL calls the host systems native functions.
3. porting sound calls:
As discussed, the miless calls would need to be ported to sdl and maybe openal.
4. porting system specific stuff:
a) First of all, shared libraries handling can get rather complex:
Using shared libraries across platforms.
Libtool provides solutions for most of these problems; within libtool ltdl provides is an interface which abstracts accessing shared libs from within your programs (both LGPL).
That way, linux, macos x and windows shared library handling would be adressed.
For cygwin, we may need dlltool, but i'm not sure about this.
b) Other system related stuff:
For supporting other platforms than linux and windows on x86 (e.g. ppc), using autoconf/automake would ease things a lot.
Both are under GPL. Distributing source of these generators is allowed under the licence of its input, too (i.e. the EULA).
This not only allows a much simplified Makefile handling, but also eases other system dependent stuff a lot (mainly handling conditioned system programming stuff and corresponding headers), though providing a unique configuration mechanism.
I could also work on this part.
See: GPL FAQ
Distributing configure scripts
Distributing Makefile.ins
A very good point to start:
Autobook
5. Writing portable c++ code:
There are several guides, but most of my links are outdated because i learned the part i wanted to know meanwhile.
Still a good point to start is:
Writing portable c++ code.
Ok., i'm not through the source completly, perhaps there's something i missed.
So far i don't know how the linux port progressed. I hope i get access to the modifications soon, so i can start at some point.
Ciao
Holger
Comment