Looking for info: Cross-Platform

Hey, im looking for more info into making libraries cross-platform, examples would be nice, descriptions, links anything you can provide. My google searches always come up with a mass-list of other people's cross-platform libraries, and no info on actually making them cross-platform.

For info: Im working on a simple console library, change colors etc and it currently supports both win32 and unix via a collection of preprocessor includes..

Code:

---

#if defined _WIN32

// code here

#elif defined __unix

//code here

#endif

---

Is this the method that other people use when designining and creating cross-platform libraries, or is this just the nub method of doing it?

Any info would be great. Thanks.

You'll want to use standard code as much as you can, but where this is not possible, yes this is generally how you use nonportable code in a cross platform manner.

Something like this:

Code:

---

// screen.h
#ifdef SCREEN_H_INCLUDED
#define SCREEN_H_INCLUDED

typedef struct screen_obj screenObj;

screenObj *myScreenInit( void );
void myScreenClear ( screenObj *s );

#endif

---

Code:

---

// screen_win32.c
#include "screen.h"
#include <windows.h>
struct screen_obj {
  int  a;
};

screenObj *myScreenInit( void ) {
  screenObj *s = malloc( sizeof(*s) );
  s->a = 42;
  return s;
}

void myScreenClear( screenObj *s ) {
  printf("%d\n", s->a );
}

---

Code:

---

// screen_linux.c
#include "screen.h"
#include <ncurses,h>
struct screen_obj {
  char *p;
};

screenObj *myScreenInit( void ) {
  screenObj *s = malloc( sizeof(*s) );
  s->p = "hello";
  return s;
}

void myScreenClear( screenObj *s ) {
  printf("%s\n", s->a );
}

---

Code:

---

// main.c
#include "screen.h"
int main ( ) {
  screenObj *s = myScreenInit();
  myScreenClear(s);
  return 0;
}

---

Now the real magic is:
For a win32 project, you compile main.c and screen_win32.c
For a Linux project, you compile main.c and screen_linux.c

Porting to another platform, you just write a new screen_xxx.c file.

main.c at that point couldn't give a hoot.

Notice in the header file, the screen is declared as an incomplete type. This means that all main can ever do is maintain a pointer and never dereference it.

Also note that inside each implementation file, the struct is declared to be whatever we need it to be. Maybe you don't need an object for the win32 case. But it generally makes for easier porting later on if you do need one.
It also easily paves the way for multi-screen use :)

Erm, this is C++, though? While certainly Salem's methods are good for writing portable code, the code itself is less good for C++ and more so for C...

Thanks for the info. So it seems its just different source files and different makefiles then for the "professional" method. Hmm, Isn't the preprocessor if statements a better method? (well at least for smaller functions). If im missing something then let me know please.

Consider that if this were a large project with many people working on it, that the person responsible for the win32 version may be different to the person responsible for the linux version.

Separate files - no dependencies, except for API changes.
One big file - merge hell.

> Hmm, Isn't the preprocessor if statements a better method? (well at least for smaller functions
How small?
#ifdef WIN32
#elif DOS
#elif LINUX
#elif BSD
etc etc

Half a dozen systems, and your few line function is a page long.


> Hmm, Isn't the preprocessor if statements a better method? (well at least for smaller functions
Alternative answer.
For the most part, you can clump all the *IX systems together under say screen_posix.c
Over large chunks of POSIX, most of them do the same thing. Using the pre-processor to sort out the minor differences is perhaps a good thing.


There is no single answer, just a box of tools to play with.
But FWIW, having some ideas before you start is a hell of a lot better than simply doing a bunch of stuff and then realising "Oh, I need to port it to fluglesys" as well.

Cheers for the info. Time to head back and starting hacking away into seperate sources then, and there was me all big headed that i managed to get something to work on two systems with little effort lol... OK next question, instead of starting a new thread, altho it prolly should go in linux programming section...

CMake or GNU make?

currently ive got my library setup to use Cmake, generally as its massively easier to create the makefiles, (ive no clue how to start with configure scripts/makefiles etc). Based on peoples experiences, is there any difference to what method you use to get a program compiled, or is it just developer preference?

> CMake or GNU make?
I've no idea - check availability on your intended target systems.