A couple of examples of design decisions that need to be pinned down early:
- POSIX Layer
Utility functions and class methods in wxWidgets are loosely based on a POSIX type structure. This means that some sort of POSIX-like layer is inevitable. AmigaOS isn't POSIX compliant, but it has most of the features from POSIX, though sometimes implemented in a different way. Amiga also adds some things that don't exist in POSIX, the file deletion protection bit being one of them. Volumes and assigns are two other basic concepts that have no direct match in POSIX. How and where to map from POSIX to AmigaOS type API's does require a little bit of design. - Network Layer
BSD sockets is the de facto standard for pretty much all networking code (these days) on just about any platform. So wxWidgets uses a sockets type API for networking and AmigaOS provides sockets type API's. If it only stopped there!! Traditionally, AmigaOS has had some variations on network API's, and while they are all similar to sockets, they are also not completely drop-in compatible. Not with BSD sockets and not with each other. What type of networking SDK is delivered with different compilers is also inconsistent. Design decisions in this area are mainly centered on which compilers and network packages to support. Not so difficult for AmigaOS 4, but when considering OS3, AROS and Morhphos there are some things to plan for.
For basic testing I'm using a (modified) version of gcc and cross-compiling from Linux. I'm more or less treating the Amiga as an embedded system, and I've moved all parts of the edit-compile-test cycle to a single non-native environment. That's why you see UAE, m68k and OS3 below, but I've taken some steps to ensure that what I'm testing is also relevant on a native ppc box.
Anyway, just to show a little bit of progress I'm including the basic sequence used to build a minimal library and a screenshot of running a trivial shell program. It doesn't really prove anything other than having a working tool chain. This would be trivial for most software projects, but for wxWidgets there's actually a fair bit of work even to get to this point. The build system is very elaborate and uses special tools, configuration files and scripts. For a smaller port I might make different decisions, but wxWidgets is a package with 1.3 million lines of C++ code -- quite possibly larger than all of AmigaOS itself. Making sure that I get a tool chain and build system that is mostly in line with what wxWidgets expects makes many other things a lot easier. Fortunately, once you get across the initial hurdle, wxWidgets is a pretty clever piece of code!
andreas@fenix-ubuntu ~/src/wxWidgets/build/amiga
$ ../../configure --host=m68k-amigaos --disable-gui --disable-all-features --disable-shared --disable-sockets
...
Configured wxWidgets 2.9.4 for `m68k-unknown-amigaos'
Which GUI toolkit should wxWidgets use? base only
Should wxWidgets be compiled into single library? no
Should wxWidgets be linked as a shared library? no
Should wxWidgets support Unicode? no
What level of wxWidgets compatibility should be enabled?
wxWidgets 2.6 no
wxWidgets 2.8 yes
Which libraries should wxWidgets use?
STL no
jpeg none
png none
regex no
tiff none
zlib no
expat no
libmspack no
sdl no
andreas@fenix-ubuntu ~/src/wxWidgets/build/amiga
$ make 2>&1 | tee make.log
...
andreas@fenix-ubuntu /build/amiga/tc-test/wx
$ cat wxhello.cpp
#include <wx/wx.h>
#include <wx/wxcrt.h>
#include <wx/string.h>
int main(void)
{
wxPuts("Hello, wxWidgets!");
return 0;
}
andreas@fenix-ubuntu /build/amiga/tc-test/wx
$ m68k-amigaos-g++ -c -o wxhello.o wxhello.cpp `~/src/wxWidgets/build/amiga/wx-config --cxxflags`
andreas@fenix-ubuntu /build/amiga/tc-test/wx
$ m68k-amigaos-g++ -Wl,-allow-multiple-definition -o wxhello wxhello.o `~/src/wxWidgets/build/amiga/wx-config --libs`
No comments:
Post a Comment