adding cygwin support

[GoogleCodeExporter]

What steps will reproduce the problem?
1. install cygwin/cygports with python, openAL, openGL, X11, g++,...
2. launch cygwin term
3. go to trunk/dev
4. python scons.py

What is the expected output? build success
What do you see instead? build errors
What version of the product are you using? trunk
On what operating system? cygwin
Please provide any additional information below.
Patches :
- Add these few lines in libsndfile.py allows to successfully compile all 3rd 
parties
- Add this to MFile.h: #include <stdarg.h>  // needed for va_list 
- Add this to MGLContext.cpp :  #elif __CYGWIN__    #include <GLee.h>
- Next step : MX11Window.cpp does not compile because no XF86 extension, 
MWin32Window.cpp does neither because no directX. Thinking about implementing 
either a MSDLWindow, or enhancing MX11Window with not using XF86VideoMode if 
not present. 
Please anyway tell me if you accept these changes before I continue.
Regards
S.

Original issue reported on code.google.com by skaiw...@gmail.com on 21 Aug 2012 at 10:08

Attachments:

• libsndfile.py

[GoogleCodeExporter]

solution 3 : implement a MGLUTWindow...

Original comment by skaiw...@gmail.com on 22 Aug 2012 at 9:32

[GoogleCodeExporter]

corection : the MWin32Window does not need directx, just direct.h. should be 
compilable on cygwin...

Original comment by skaiw...@gmail.com on 22 Aug 2012 at 9:34

[GoogleCodeExporter]

Someone compiled Maratis with Mingw : 
http://forum.maratis3d.com/viewtopic.php?id=321

Normally everything should compile, the problem might be more with scons not 
recognizing the platform.

What are the build errors ?

Original comment by anael.se...@gmail.com on 23 Aug 2012 at 10:38

[GoogleCodeExporter]

We might need to modify dirent.py to pass when using CYGWIN, as cygwin don't 
need the win32 dirent port

Original comment by anael.se...@gmail.com on 23 Aug 2012 at 10:57

[GoogleCodeExporter]

Hi Anael,
1 - nowadays mingw and cygwin are more and more different but at first there 
was the same issue in MFile.h that you did not fixed : you have to add this to 
MFile.h: 
#include <stdarg.h> // needed for va_list 
Why did n't you fixed it ?
2 - I have fixed some scons file as described for example in joined file 
libsndfile.h 
3 - dirent.h seems available on cygwin so we could use it if needed.
4 - could you apply these changes before I continue or not ?
Kind,
S.

Original comment by skaiw...@gmail.com on 23 Aug 2012 at 8:32

[GoogleCodeExporter]

do you still get errors ?
can you send me a svn patch of your fix so I can apply it ?

Original comment by anael.se...@gmail.com on 24 Aug 2012 at 7:40

[GoogleCodeExporter]

added stdarg to svn

Original comment by anael.se...@gmail.com on 28 Aug 2012 at 2:21

[GoogleCodeExporter]

Hi Anael, please excuse, was on holidays.
Here is the diff.
S.

Original comment by skaiw...@gmail.com on 28 Aug 2012 at 7:46

Attachments:

• cygwin.diff

[GoogleCodeExporter]

Consequently, Anael, what would you prefer in order to finish cygwin support ?
1 - implement a MGLUTWindow ?
2 - implement a MSDLWindow ?
3 - enhance MX11Window to work with or without XF86VideoMode ?
4 - fix Win32 Window to compile under cygwin : there is currently some 
compilation errors when :
#ifndef (__CYGWIN__)
    #include <direct.h>
#endif

Original comment by skaiw...@gmail.com on 28 Aug 2012 at 7:54

[GoogleCodeExporter]

Hi, thank you.

X11 should work, xf86VideoMode is mainly used for fullscreen mode.

Can you check if cygwin have <X11/extensions/Xrandr.h> ? If there is Xrandr, it 
can replace xf86VideoMode for the fullscreen mode, if not, the fullscreen mode 
can just be disabled.

Original comment by anael.se...@gmail.com on 29 Aug 2012 at 9:09

[GoogleCodeExporter]

Hi Anael
 OK thanks.
 You have still not patched libsndfile.py as I propose.
 Waiting for this before continuing.
S.

Original comment by skaiw...@gmail.com on 29 Aug 2012 at 5:30

[GoogleCodeExporter]

Ok, I applied your patch with a little modification for MWindow, it's using X11 
with XF86VideoMode disabled. It should work but without fullscreen mode, if you 
can test.

If everything works, we can then use Xrandr to get the fullscreen back.

Original comment by anael.se...@gmail.com on 29 Aug 2012 at 6:24

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

glGenerateMipmapEXT and all extensions are generated by glee.c

Original comment by anael.se...@gmail.com on 30 Aug 2012 at 8:00

[GoogleCodeExporter]

I looked at glee.h, I'm not sure weather for cygwin it need to use the WIN32 
includes or the X includes, maybe you can try adding "|| __CYGWIN__" in glee.h :

#ifdef WIN32 || __CYGWIN__
        #define WIN32_LEAN_AND_MEAN
    #include <windows.h>
    #include <GL/gl.h>

Original comment by anael.se...@gmail.com on 30 Aug 2012 at 8:10

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I think it's in <GL/glx.h>, at least in linux.

Should it not use the wglGetProcAddress one ? with defining a #ifdef WIN32 || 
__CYGWIN__

?

Original comment by anael.se...@gmail.com on 30 Aug 2012 at 10:24

[GoogleCodeExporter]

glXGetProcAddressARB is indeed in usr/include/GL/glx.h :

/*
 * ARB 2. GLX_ARB_get_proc_address
 */
#ifndef GLX_ARB_get_proc_address
#define GLX_ARB_get_proc_address 1

typedef void (*__GLXextFuncPtr)(void);
extern __GLXextFuncPtr glXGetProcAddressARB (const GLubyte *);

#endif /* GLX_ARB_get_proc_address */

but the error is a link error, not a compile error.
Lets check win32...

Original comment by skaiw...@gmail.com on 31 Aug 2012 at 10:55

[GoogleCodeExporter]

wglGetProcAddress is indeed in lib/w32api/libopengl32.a
I have added this lib in the link process : -lopengl32
but if I modify glee.c to point to wglGetProcAddress 
then several undefined reference to `_wglGetProcAddress'

Original comment by skaiw...@gmail.com on 31 Aug 2012 at 11:08

[GoogleCodeExporter]

10.4. Problems linking OpenGL applications? Undefined reference to _glsomething?
Cygwin has two OpenGL implementations:

- headers in /usr/include/openGL, libraries (-lglut32 -lglu32 -lopengl32) from 
the opengl and w32api packages which are for displaying OpenGL graphics 
directly through the native Windows interface (Win32) without any X server

- headers in /usr/include/GL, libraries (-lglut -lglu -lgl) from the Mesa libGL 
packages (libGL-devel, libGL1, libGLU-devel, libGLU1, libglut-devel, libglut3, 
freeglut) which are for displaying OpenGL graphics through an X server.

These are incompatible, even the headers (as the native OpenGL API has the 
stdcall calling convention), so you must exercise care if you have both sets of 
devel packages installed. An application must be built using only one of these.

- X applications using GLX must be built using option 2.
- Applications using GLUT have a choice.
- Applications using the WGL API must be built using option 1.

...

Original comment by skaiw...@gmail.com on 31 Aug 2012 at 1:02

[GoogleCodeExporter]

I found on Internet that there is an option to force the compatibility to WIN32 
to compile like mingw but with cygwin :

gcc -mno-cygwin

Don't know if it can be of use

Original comment by anael.se...@gmail.com on 31 Aug 2012 at 2:12

[GoogleCodeExporter]

I have added self.CppCommonFlags  = '-mno-cygwin' in compileroptions.py : 
g++: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler.
This is probably when using mingw compiler, not the usual cygwin g++. Swaping 
ot mingw would be too much work and normal g++ should work.

Original comment by skaiw...@gmail.com on 31 Aug 2012 at 4:28

[GoogleCodeExporter]

I have created a cygwin section in compileroptions.py and here is the current 
work in progress status :

1 - if defining WIN32 with 
self.CppCommonDefines  = 'WIN32 _MBCS' 
and using MWin32Window, everything compiles fine but when linking 
ManualUse.exe, there are some undefined references as _joyGetDevCaps ... even 
if I add winmm and other libs... through 
env.AppendUnique(LIBS = ['winmm', 'User32', 'Shell32', 'Gdi32', 'Comdlg32', 
'glaux'])

2 - if not defining WIN32, swaping to MX11Window, everything compile fine but 
ManualUse.exe failed to link with : undefined reference to `_glXGetProcAddress' 
or undefined reference to `_glXGetProcAddressARB' 

The changes does not touch any existing supported platforms. Could I/you commit 
?

Original comment by skaiw...@gmail.com on 31 Aug 2012 at 4:43

[GoogleCodeExporter]

I think the good way should be WIN32.

I found some code on GLFW with a makefile for cygwin : 
http://www.koders.com/noncode/fid8456C569443C61785EFB44846BA7777B191D8D98.aspx?s
=%22mercy%22

I've seen they use this additional include for cygwin (should be added to the 
WIN32 MWindow) :

#if defined(__MINGW32__) || defined(__CYGWIN__)
#include <w32api.h>

Original comment by anael.se...@gmail.com on 31 Aug 2012 at 5:16

[GoogleCodeExporter]

I commit the w32api.h modification and port the dependency to direct.h

Original comment by anael.se...@gmail.com on 2 Sep 2012 at 9:49

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi,
nice work, thanks !
William, I added you to the project, you can normally commit to svn.

Original comment by anael.se...@gmail.com on 3 Sep 2012 at 8:28

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

here it is, that works : to be carefull, to resume :
- the order of libs is important : for example glee must be before opengl32
- the GL headers are important : for WIN32 compilation, do not use the 
/usr/include/GL but /usr/include/w32api/GL ones

Original comment by skaiw...@gmail.com on 4 Sep 2012 at 7:50

Attachments:

• Sponza.gif

[GoogleCodeExporter]

Perfect, so I'm closing this,
good work, thanks !

Original comment by anael.se...@gmail.com on 6 Sep 2012 at 3:44

• Changed state: Fixed