Bug in SDL_image configure ? And other SDL topics

Hi all,

I am working on an online auto-installer for our library based upon SDL
1.2.7 (http://osdl.sf.net), but the windows version fails installing
SDL_image 1.2.3 using Cygwin : the configure step fails, because it is
unable to find the main SDL include file (SDL.h) despite the
"–with-sdl-prefix=…" being correctly set (the corresponding -I…
does not appear when configure test compile “to be sure SDL > 1.2.4 is
available”, when looking at config.log). I can disable the test with
–disable-sdltest, but of course the library itself won’t compile
afterwards for the same reason. I guess the configure script might be
fixed, but I am unable to correct it (I do not know yet how to handle
autoconf and other similar tools).

Anyway, I had a few more questions about SDL, which, I think, is a great
library indeed.
Our project is mainly developed under Linux environment, but of course
we all wish to have it working with windows too, and, furthermore, cross
compiling would not suffice since some of our “team members” would like
to stick to windows, even for developing. My concern is also to respect
as much as possible the “UNIX way of building”, i.e. GNU make, libtool
and so on, with only open source tools (Visual Studio set of tools is
not an option for us). We therefore thought of mainly two other solutions :
- use Cywin (I was a bit disappointed using it)
- use MinGW + MSYS (I have not tried it yet)
We will soon have to work with iMac too (mainly Panther and Jaguar, as
far as I know), we thought to Fink, we would like not to waste time
struggling against frameworks, XCode and related.

Could you confirm us that these are the three most convenient ways to do
so the UNIX way, in respect with SDL and its helper libraries needs ?

Should we, while using at least two of those three environments, even
with some pain, end up with a fully working version under windows and
MacOSX of SDL and its helper libraries together with our code, whose
binaries could be distributed with only executables and libraries,
without running into too serious performance issues ? (technically I
mean, we already took care of the legal aspects and that’s all right). I
guess some overhead might be expected because of the “abstraction
layer”, for example cygwin1.dll translating UNIX calls to Windows ones.
Maybe it just does not matter, I do not know, I just would not like
investing too much efforts in a technical dead end !

Thanks in advance for any hint,
kind regards,

Olivier.