gamedevlists-general

[GD-General] Minor rant - cross-platform configuration

[brian h. <bri...@py...>]

In the process of working on some of our internal source that I will 
eventually be open sourcing, I needed to come up with a "config.h" that 
handles per-platform dependencies.

Looking at the plethora of open source libraries I use -- zlib, libpng, 
ijg, Lua, SDL, etc. -- I was appalled at the amount of repeated work 
done for the most basic task: configuring your build environment and 
targets.

This is something that should have been mostly figured out years ago, 
and yet everyone rolls their own.  Every project has a header file that 
basically is chock full of this kind of loveliness:

#if defined _WIN32 || defined __WIN32__
#if defined __BORLANDC__ || defined _MSC_VER
#if EXPORTING_DLL
#define PUBLIC_API __declspec(dllexport)
#elif IMPORTING_DLL
#define PUBLIC_API __declspec(dllimport)
#endif
#endif
#endif

#ifndef PUBLIC_API
#define PUBLIC_API
#endif

.
.
.
PUBLIC_API void MyLib_SomeFunction( void );

And then we have similar drills for type sizes, compile time 
assertions, operating system, compiler, CPU, endianess, you name it.  
Configuring 64-bit types; calling conventions; etc.

It's not rocket science.  It's just tedious crap that everyone has to 
write from scratch and learn the hard way.  Simple things aren't so 
simple -- "How do I know if I'm compiling for MacOS?"  or "What kind of 
endianess is this architecture?"

For example, if "__sun" is defined, you cannot assume Solaris nor can 
you assume Sparc.  You have to look at the __sparc/sparc and __SVR4 
constants, because you may be on Solaris/x86 or SunOS for Sparc or even 
68K/x86.  A lot of people assume that __MWERKS__ means "MacOS", but 
that's not true either.  There's no universal constant for MacOS X, so 
you have to looked __APPLE__ and __APPLE_CC__ or something else if 
__MWERKS__ is defined.  

If __mips is defined, it may mean many different things, but a lot of 
people will assume immediately "Irix" and "big endian".  Can't do that.

Borland defines __WIN32__, but not _WIN32.  MSVC is the opposite.  God 
knows what's going on with Watcom these days, but sadly enough, people 
still use it.

And don't get me started on MingW and Cygwin.

Bah.  It's depressing.

Anyway, I'm writing a single generic header file that's going to be 
used by all of our ANSI C libraries, and I'll open source that 
hopefully to help others avoid the frustration as well.

Current working name is "gosh.h" for Generic Open Source Header.  I'm 
trying very hard to make it "plug and play" -- simply including it will 
automagically setup everything, so you don't have to deal with a bunch 
of -DMAGIC_CONSTANT=x or "./configure" and what not.

Adjunct to this rant -- so far I've only found one site (off 
sourceforge) that even tries to catalog all the various compiler 
definitions for different operating systems, compilers, and 
architectures.  

-Hook

Re: [GD-General] Minor rant - cross-platform configuration

[Javier A. <ja...@py...>]

brian hook <bri...@py...> wrote:

> This is something that should have been mostly figured out years ago,
> and yet everyone rolls their own.
[...]
> Anyway, I'm writing a single generic header file that's going to be
> used by all of our ANSI C libraries,

You asked the question, and then indirectly answered it yourself. The wheel
was invented a long time ago, but there are hundreds of different wheels in
the market today.

  Javier Arevalo
  Pyro Studios

Re: [GD-General] Minor rant - cross-platform configuration

[Colin F. <cp...@ea...>]

2002 November 6th
Wednesday

> > This is something that should have been mostly figured out years ago,
> > and yet everyone rolls their own.
> [...]
> > Anyway, I'm writing a single generic header file that's going to be
> > used by all of our ANSI C libraries,
>
> You asked the question, and then indirectly answered it yourself. The
wheel
> was invented a long time ago, but there are hundreds of different wheels
in
> the market today.

I might be wrong here (I'm still recovering from Election
Night depression), but I thought Brian was offering to
end the "reinventing the wheel" pattern by posting a
definitive header file that should satisfy the needs
of most cross-platform developers.  The reason these
devlopers "rolled their own" header files was because,
I suppose, a standard header file had never been
created or published.  Just as the initiative that
led to the Standard Template Library (STL) now saves
many developers from having to make the same basic containers
and algorithms, perhaps GOSH will save developers
from having to enter the world of arcane compiler
variables and directives.  Sure, there will be people
that want custom headers, just as some people need to
avoid STL.

Anyhow, as far as having "hundreds of different wheels in
the market today", it's not because consumers desire
variety.  No, it's because "The Man" knows that
open standards and compatability might mean that His
products actually need to compete for consumer's
cash.  "The Man" is not interested in the welfare
of the consumer beyond the ability to produce more
things to be consumed, and the ability to buy stuff
(preferably invisible stuff, like derivative stocks
and phone sex).

So, we have the Sony wheel, with its memory stick,
funky cables, and wacky batteries.
Then there's the Microsoft wheel, which requires you to
get a ".NET Passport", a "hotmail" account and spam, and
always keep your wheel online so it can call home.
The MSN 8.0 wheel is just as good as the AOL 8.0 wheel.
The Cingular wheel allows you to drive around a little
more next month if you didn't drive around so much this month,
like that's an excuse to switch from some other wheel.
Verizon has a wireless wheel, but to have any fun
with it you have to get a Microsoft wheel and pay
money for "Get It Now!".  (AT&T also has a wireless
wheel, but anyone can mess with their own wheel.)
RealNetworks has the "Real One" wheel, which gathers
information about where the wheel has been, a lot
like the Microsoft Media Player wheel does.
GameCube, PS2, and XBox wheels don't work together
at all; you have to choose where you want to
roll, unless you're willing to buy all three
wheels.  For all the wheels mentioned above, you
should buy the wheel you see the most on television,
especially if the wheel is shown next to a popular
but totally unrelated wheel.  Vote for the wheel
that will lower taxes, and then freak out when
hospitals, schools, parks, libraries, roads,
homeless shelters, clinics, fire stations, and police
stations start closing.  Forget about domestic issues
and the economy, and expand programs to "defend"
our wheels against vague threats halfway around
the globe, without the support of most wheels in
the civilized world.

The true dream of "The Man" is to create an attractive
wheel whose operation is completely secret, and then
achieve market saturation by dumping these wheels all
over the world for free (or far below cost), and then
license and lease the ability to make the wheels roll.
Only through partnership with "The Man" can you hope
to compete with others who are already partners with
"The Man".  Eventually, when a partner of "The Man"
becomes really successful, "The Man" will assimilate
the essence of the partner just to eliminate the gap
between "The Man" and pure profit.

That's the Amazing(r) Story(c) of "The Man(sm) and His Wheels(tm),
LLP", all rights reserved, patent pending, registered trademark,
copyright, etc.

If you do not agree to the terms of this e-mail,
OR CRAZY LEGAL PARAGRAPHS WRITTEN IN ALL UPPERCASE LETTERS,
or any of the 1000 paragraphs in the EULA that you
couldn't possibly have read in the 1.3 seconds before
you finally preceive and immediately press the
"I Agree" button, then return all materials in
the original packaging to the manufacturer for a
"full refund"(*), in the form of a voucher that allows
you to purchase some of our other products.
Please allow 8 to 200 weeks for delivery.
Not responsible for goods damaged or lost in the mail.
Before returning any product, you must notify us
in writing, and you must register online with a
telemarketing database.  You must send the original
store receipt, a notarized affadavit, a self-addressed
stamped envelope, tax returns, and medical records.
If, God forbid, there's actually competition in this
domain, we will charge an early termination fee when
you finally wake up and switch to a better product.
If you fail an arbitrary credit check, we'll increase
the cost of the product by 50% as a convenience to you,
and this amount is non-refundable even if you return
the product.

  [ ] I Disagree, even though I drove all the way to
the computer store, paid $400 for this software,
have a strong desire to do something productive
with the software, and already did most of the
installation steps.  There was a tiny clause in
the EULA that I just cannot accept, despite the
fact that the overwhelming elements of the program
do just what I want.  Sure, the next best software
out there may be used by only 2% of the market,
but I'm willing to enter obscurity and alienation
if it means that GiantCorporation won't make me
make yet another concession in my privacy.
I know that eventually the OS will fundamentally
invade my privacy, and checkboxes will revert to
allowing full disclosure, and minor incidental
software upgrades will totally change the agreements,
but I'll take a silly stand against these things
even when the federal government will let
GiantCorporation do whatever it wants anyhow.

  [ ] I Agree.  Okay, I didn't really read the
EULA.  I trust that GiantCorporation will do what's
best for me.   I kind of like WWW sites that greet
me by name.  The targeted advertising and e-mail
is just great.  Actually, it's kind of reassuring
to know that GiantCorporation is checking if I
have any pirated music, images, or software on my
computer, and checking my documents for any
anti-establishment talk.  When ObscureCorp enforces
an all-encompassing patent on "interactive software",
I'll automatically be billed for royalties.
In general, renting is better than buying; it
keeps me from owning things, and I get to spend
money on an ongoing basis and gives me a thrill of
imagining what might happen if I lost my job.
Maybe I can save some money if I leased some
of my software on an hourly basis.  I'm hoping
that GiantCorporation can devise a closed system
on my own desktop, monitoring all files, and
managing my life -- like I'm part of a giant
club, where everyone likes the same music, movies,
video games, and GiantCorporation's version of
the news.  It's easier when we're all the same!
I hope GiantCorporation makes us all the same,
of a single mind, at equilibrium, in perfect
harmony with GiantCorporation.  Yes, I Agree!


--- Colin
cp...@ea...

Re: [GD-General] Minor rant - cross-platform configuration

[Javier A. <ja...@py...>]

Colin Fahey <cp...@ea...> wrote:

> I might be wrong here (I'm still recovering from Election
> Night depression)
[...]

Don't worry, a couple of of white-dressed very nice men will come in a few
minutes to take you a much better place where you will be very happy and
everything will be all right. ;-)

  Javier Arevalo
  Pyro Studios

RE: [GD-General] Minor rant - cross-platform configuration

[Brian H. <bri...@py...>]

> Night depression), but I thought Brian was offering to
> end the "reinventing the wheel" pattern by posting a
> definitive header file that should satisfy the needs
> of most cross-platform developers.

That's exactly what i'm saying.  It's obvious that this problem has been
solved before.  In lots and lots of different ways.  In fact, if you
look at any popular open source library, you'll see a "configurator"
file that basically does environment inference.  SDL, Lua, Apache,
MySql, zlib, libpng, ijg, Python, Mesa, Qt, wxWindows, etc.  The list
goes on, and each of them re-invent the wheel.

And for many of the GPL/LGPL ones, if you take their wheel, you've
"infected" your own source base in the process.  And, of course, a lot
of those wheels are overkill (support for PDP-11); incompatible (need
C++); encumbered (GPL/LGPL); difficult to use (require manual definition
of key constants); difficult to integrate (don't use prefixes and thus
pollute the namespace); etc.

They all work well for their intended purposes, but excising just the
configuration elements can be time consuming and painful.

> The reason these
> devlopers "rolled their own" header files was because,
> I suppose, a standard header file had never been
> created or published.  

Exactly.  The mere fact that something as obvious as a comprehensive
central repository for compiler defined constants on various
architectures doesn't exist is pretty damning.

Thankfully someone is at least making an effort:

http://predef.sourceforge.net/

I have no idea how anyone finds the above, because it didn't turn up on
any of my searches until about an hour into this last night, several
pages back.  In fact, I still have trouble having it show up in a search
engine when entering words straight off the page.

It also lacks comments on where/how/when things are defined -- the
constants are both compiler and target platform dependent.  So _WIN32
might be defined on MSVC, but it's __WIN32__ on Borland.

But at least someone has recognized the value of having this documented.

> and algorithms, perhaps GOSH will save developers from having 
> to enter the world of arcane compiler variables and 
> directives.  Sure, there will be people that want custom 
> headers, just as some people need to avoid STL.

That's my intention.  And it will be totally unencumbered.  It's a
frigging header file, header files shouldn't haver licenses =)

That said, it's possible that it would expand over time to include other
basic functionality that you would expect, the obvious ones being
endianess utilities and architecture reporting.  There aren't that many
different ways to write "Swap16" and "Swap32", yet everyone does it all
the time.  Sometimes with functions, sometimes with macros, sometimes
with shifts/masks, sometimes with unions/swaps, etc.  And a generic
"Give me a string that tells me what platform this is" would be nice.

And, of course, all optional.  But that's for another day.

Brian