[geeks] porting OSX C++ to linux

[Jonathan C. Patschke]

On Wed, 17 Jul 2002, Joshua D Boyd wrote:

> What would be the proper way to #if that is that it is true for both
> OSX and linux?

The Microsoft Visual C++ manual (for version 6) says that _lrotl() is not
a portable function, even though it is defined in stdlib.h--it only exists
in the VC++ runtime.  Given that, wouldn't you perhaps want to check for
the lack of Visual C++ on Win32?

The proper way to do this would be sticking this in a header:

  #if !(defined(_MSC_VER) && defined(_WIN32))
  /* If we're not VC++ on Win32, assign the VC++-specific function *
   * name to something that we -know- exists and does the same     *
   * thing.                                                        */
  #define _lrotl my_lrotl

  #endif

  static unsigned long my_lrotl (unsigned long x, int r);

Then, in a central .cxx file, give the implementation of the my_lrotl
function.

Alternatively, you can use something like autoconf to test for the
presence of that function, and insert your defines into config.h.

> I must admit, my experience with cross platform projects is pretty
> minimal.  When faced with it, I seperate all my N platforms into N+1
> directories (where the N+1th directory is for platform neutral stuff),
> then try to place as much of the logic as possible in the N+1th
> directory, rather than everything sharing one codebase.

That's a sane and simple way of doing it, up to a point.  A lot of logic
is, for example, common to Solaris and Linux, but not to IRIX.  You'd end
up with duplicating code then, which is the problem you're trying to
solve, anyway.

You have to remember that you're abstracting over differences between the
platforms, not the platforms themselves (you don't really want a version
of your program for each OS).  Generally, I do division like that for
toolkits or frontends, since those are generally true abstractions.  For
example, if I have a program that has a GTK frontend and a native Win32
frontend, they'll each go in a separate directory.

What you want, for something like this, is feature-testing, and set
#defines for the presence or lack of each feature.  You don't necessarily
need autoconf to do this.  Having something like this in your Makefile
does the trick, as well.:

  # >> Generic Compiler/Linker Flags <<
  CFLAGS = -64 -O3 -KPIC -I/usr/local/include
  LDFLAGS = -64 -L/usr/local/lib64

  # >> Feature Specific Flags <<
  #
  # Do you have _lrotl (VC++ on Windows)?
  #CFLAGS += -DHAVE_LROTL
  #
  # Do you have strdup (pretty-much everywhere)?
  CFLAGS += -DHAVE_STRDUP

Then, in your code, you check for HAVE_LROTL and such.  This gets
out-of-hand (going past the maximum command line length) really quickly,
if you test a lot of features.  This is why autoconf generates a config.h,
rather than modifying CFLAGS.

-- 
Jonathan Patschke
  "gnu: we aim to fuck up everything with the potential to not suck"
                                                   --alex j avriette