In seven or eight months of trying, I've personally never found a sensible answer to any of these questions.

What isn't sensible (imho) is something like

package SDL::Build::MSWin32; ...

sub find_header
{
    for my $key (qw( LIBS PATH ))
    {
        die "Environment variable $key is empty\n" unless $ENV{$key};
    }
[download]

Do binary installations of SDL include the headers? As you know, the build will fail without headers. If you can show me a sane way to find the headers, I'll put it in the code.

Do binary installations of SDL include the headers?

Only if you get the Development Libraries ofcourse

C:\DEV\SDL_PERL\SDL-DEVEL-1.2.8-VC6
\---SDL-1.2.8
    +---docs
    |   \---html
    +---include
    \---lib
[download]

As you know, the build will fail without headers.

Yes, and the user will get a nice error message saying that SDL.h... can't be found. The user is ultimately responsible for managing those.

If you can show me a sane way to find the headers

use File::Spec;
for my $inc ( @include_dirs ){
    if( -e File::Spec->catfile( $inc, 'SDL.h' ){
        die "Congratulation, you've got  SDL.h";
    }
}
[download]

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"

I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).

** The third rule of perl club is a statement of fact: pod is sexy.

I don't know. I know that Windows isn't the greatest environment to build stuff, but thats the platform that I have to use here.

My problem with Module::Build is that when something wrong happens, I haven't a clue what I need to do to fix it. Its so frustrating! At least with MakeMaker I can look at the makefile and try to config stuff manually, by hand. I can see the dependencies. I can see which information it needs to build. I can see that it requires header files to install. A build system that requires me to be intimately familiar with its internals is useless to me.

I mean, dammit! I don't care how the thing builds, I just want to use it! I'm even very willing to spend lots of time trying to get it to install, because I need it. Its just when the build system says essentially says "sorry, the automatic configure system isn't working", and thats all the output I get, I... its just... AARRRRRGHHH!

Just a guess - you should use 'nmake' but using 'make'; or may be Config.pm is not precise enough; which way did you obtained Perl binaries

Every "recent" version of Win32 (that is, Windows 98, Windows ME, Windows NT, 2000 and Windows XP) has OpenGL installed by default, for Windows 95, OpenGL.org points to a download. This is, of course, only the SGI/Microsoft software renderer, but that is enough for a start.

The official way to query the OpenGL vendor is to load the OpenGL libary and then use the glGetString call to get the vendor string. Win32::API can easily load shared libraries and call functions in it, not unlike a module you wrote for Linux (I think). Finding the fitting OpenGL library headers is somewhat harder, as they first must be installed and second the script must find them - I would let the user specify that.

The SDL headers and additional SDL libraries should simply be inquired from the user if a sane set of defaults doesn't fit. Please do not enter into an infinite loop if there is no user present to answer your question, but bail out of the build script.

Would the appropriate Win32::API code look something like this?

use Win32::API;

my $gl_vendor = Win32::API->new(
    "OpenGL", "char* glGetString(unsigned int a)"
)->Call( 0x1F00 );
[download]

I could see looping over that and using mesagl instead of OpenGL too.

Personally, I've found the C parser of Win32::API something I don't rely on - it's a recent addition and did not seem to work in all cases. I prefer using the "pack"-style parameter templates:

use strict;
use Win32::API;

my $gl_getstring = Win32::API->new('OpenGL32', 'glGetString', 'I', 'P'
+);
die "Could not load glGetString : $! / $^E"
  unless $gl_getstring;

print "Vendor(a): ", unpack "p", $gl_getstring->Call(0x1F00);
[download]

I can't test this on my system, as both your variant and my variant seem to crash somewhere, and I don't know how this system here is set up/crippled. You need to change the library to OpenGL32 though, as that's the name of the library on Win32.

I just noticed - I had to change your call some more, before Win32::API accepted it at all:

my $gl_vendor = Win32::API->new(
    "OpenGL32", "char* glGetString(int a)"
)->Call( 0x1F00 );
print "Vendor (b): ", $gl_vendor;
[download]

I've done some work with OpenGL::Simple and have had relatively good success with it, but I haven't delved into the depths of OpenGL programming. If you want/need a test account, I can make you the same offer I already made to Michael Schwern, that you can mail me files that get run on my Win32 machine (when it's on). My personal interest in SDL is limited though, so I won't be working on it.

I've now tested this on my machine with an ATI OpenGL driver installed, and there are some more steps necessary to go through before glGetString will work, as the relevant OpenGL ICD(s) must be loaded, which doesn't happen until after OpenGL is initialized. After some short magic with Inline::C and some browsing of the MSDN, the below code is a very convoluted way to print out ATI Technologies Inc. on my machine. I've left in some warnings and didn't golf down the code, but in theory this is what should work everywhere for Win32.

use strict;
use Win32::API;

my $library = 'OpenGL32';

sub loadFunction {
  my $code = Win32::API->new(@_);
  
  die "Couldn't load $_[1] from library $_[0]: $! / $^E"
    unless $code;
  
  no strict 'refs';
  *{$_[1]} = sub { $code->Call(@_) };
};

loadFunction('USER32', 'GetDC', 'L','L');
loadFunction('GDI32', 'ChoosePixelFormat', 'LP','L');
loadFunction('GDI32', 'SetPixelFormat', 'LLP','L');
loadFunction($library, 'wglCreateContext', 'L','L');
loadFunction($library, 'wglMakeCurrent', 'LL','L');
loadFunction($library, 'glGetString', 'L','P');

my $hDC = GetDC(0) or die "Couldn't get the Device Context";
warn "Device context $hDC";

my $pfd = pack "ssVccccccccccccccccccccVVV", (40,1,0x25,24,0,0,0,0,0,0
+,0,0,0,0,0,0,0,0,16,0,0,0,0,0,0,0,);
my $ofs = pack "p", $pfd;
my $pfd_num = ChoosePixelFormat($hDC,$pfd);
die "Didn't get a (solid) pixel format: $pfd_num" unless $pfd_num;
SetPixelFormat($hDC,$pfd_num,$pfd)
  or die "Couldn't set the proper pixel format";

my $hRC = wglCreateContext($hDC) or die "Couldn't create the GL Render
+ing Context";
wglMakeCurrent($hDC,$hRC) or die "Couldn't activate the Rendering Cont
+ext";
print glGetString(0x1F00);
[download]

I'm not sure what idea the MESA GL libraries subscribe to, but in theory, they should work the same, if they are the only installed ICD.