[geeks] porting OSX C++ to linux

[Jonathan C. Patschke]

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

> 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.

Autoconf is intimidating.  It's also quite broken in a lot of respects
(especially on IRIX).  I'd like to say that it's really not as bad as it
looks, but that simply isn't the case.  It (usually) gets the job done,
but it is a pain in the ass to work with, and you will find yourself
jumping through stupid, needless hoops just to keep it happy.

> I mean, just look at gnu hello.

I keep hoping that GNU hello is a tongue-in-cheek joke, and not really
what the GNU project would expect from a minimalistic, tiny software
project.

> 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.

If he doesn't like you making his code more maintainable and portable,
he is a wanker, and you should very-definitely fork the code.

> It needs a better name anyway.  Major contributer to a project named
> renderBitch is not something I want to put on my resume,

That's a matter of personal choice.  It doesn't sound any more offensive
than "major contributor to Microsoft Windows", but that's all a matter of
context.

> 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.

That's how I'd do it.  I'd have the sound be in a separate module (either
a single binary object, or a library) and expose a common API to the rest
of my program.  Again, abstraction.

In fact most of my programs have the entire core logic rolled away into a
library, with -only- the frontend present in the executable file.  It
makes adding things like scripting and batch-mode frontends very easy and
straightforward.

>  I guess this would be where autoconf would come in...

Maybe, but it can be done with regular makefiles just as easily.  The make
utility is an extremely powerful tool.

> > 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.

Yeah, an autoconf-generated or hand-written config.h really is the way to
go.

> 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).

Gak!  If gcc is spitting out warnings, the code really -must- be
ambiguous.  Throw some explicit typecasts in there to Say What You Mean.

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