[geeks] porting OSX C++ to linux

[Joshua D Boyd]

On Wed, Jul 17, 2002 at 12:03:24AM -0500, Jonathan C. Patschke wrote:

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

I'd like to autoconf it at some point, but I've never set up on
autoconf project and find the prospect to be rather intimidating.  I
mean, just look at gnu hello.  I don't know what the maintainer of the
program would think of doing all this, but if he doesn't like it, I'll
just fork it since it is GPL'd.  It needs a better name anyway.  Major 
contributer to a project named renderBitch is not something I want to
put on my resume, but this renderer does some pretty sophisticated
things, and for once I can grok the code well enough to be working on
it. 
 
> > 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.

True.  So far I've been able to get away with treating all unix like
OSs the same, but that is in part because this hasn't been for audio
software. 
 
> 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.

So what if frontend A is uses gtk and /dev/dsp, but frontend B uses
gtk and dmedia?  Ideally the gtk part of the front end would be common
and only the audio split apart.  I guess this would be where autoconf
would come in...
 
> 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.

Interesting.  I can see how that would get out of hand.  Luckilly, the
bit about LROTL is the only thing I see that needed changing between
platforms.  The gui is done in GLUT, and ever other piece of the
program just worked (although GCC spit out a lot of warnings about
dubious number conversions).

-- 
Joshua D. Boyd