Bruno Medeiros wrote:

>> But I just updated the old versions that were provided by DedicateD,
>> and are also available from Japan: http://shinh.skr.jp/d/porting.html
> 
> Huh? I don't understand what you mean here. Where your bindings also based on DedicateD? What what does that have to do with the D-Porting bindings and why did you mention it?

AFAIK (my japanese isn't too good), those japanese ports are based on the versions from DedicateD (http://int19h.tamb.ru/files.html) and they are based on the same "idea" that the ones I did - i.e. just port them.

I just started mine over from "scratch" (i.e. the original C headers)
both for copyright and for updating reasons. The end results is very
similar though, and they are both in the "opengl" and "sdl" modules.

So I think all of these should all be source-compatible, for instance ?

>> A recent post included more modern/open source versions of the headers,
>> built from Mesa OpenGL and FreeGLUT instead of "my" SGI OpenGL and GLUT.
>>
>> http://www.digitalmars.com/d/archives/digitalmars/D/announce/2982.html
> 
> *Sigh*, yes, another binding to the mix. Like you said it seems similar to Derelict, except it is based on different GL headers?

It's similar to the ones above, in that is based on a port of C headers.
(seems to include more headers though, including the "platform" GL ones)

Derelict is based on a different idea, namely loading function pointers?

> I (currently) don't know enough about OpenGL to know the differences (and thus the advantages) between those newer/older opengl headers, so I don't know how more useful that binding would be over Derelict. (Meaning I'd rather use Derelict over that one)

I think you understood the difference just fine, with your posting...
(they differ in automatization, and how they link to the libraries)

>> Basically I just include everything in sdl/*.d and link it with SDL ?
>> (similar to how you use it from C, so it's wasn't very documented no)
> 
> No, you *also* have to link with the SDL_D libs, right? (This is something that must be mentioned.)

The only tricky part is that Mac OS X can't use the regular SDLmain, but must use a SDLmain_d that has been patched to use a different "main" name so that the D and the Objective-C startup can co-exist nicely...

The other libraries are just a convenience that I used so that I didn't have to include all the of the source code files with every compilation.
But you *can* do that just fine, with the regular DMD syntax: gdmd *.d

(well, at least that was the idea - maybe it was messed up in practice)

>> The other ones just had implicit names, since they're all in "sdl"...
> 
> I know they have implicit names, I can see that myself :P
> But it is still broke. It works *only* if you compile each module separately, *and* if you only import sdl.sdl (or sdl.main) in your application. (if you import certain other sdl modules it breaks)
> Surely you agree this is not proper behavior.?

I do, but it worked for me when I put it in my /usr/include/d/sdl...
But I'll add the module names at the top of each file, to "fix" it.

>> Once I update the headers to SDL 1.2.10 (etc), I will package it up too.
>> It will probably only work with GDC, but Derelict is good for DMD use ?
>>
> Whoa! "will probably only work with GDC" !?  :|
> (And MikeP also mentioned that Derelict didn't work with GDC as of yet) 

My main target is GDC and Make. I know that others prefer DMD and Build,  which is why I suggest that other libraries might be better if you do ?

In theory all the platforms belongs the same "GNU" target interface...
But I usually test my releases on Mac OS X, Windows XP and Fedora Core.

> Are GDC and DMD so far off from each other that it is hard to build code that works in both?! What kind of things are working differently? (I only know of 'the lack of newer D features', and 'the typeof ==/is problem', both of which don't seem very problematic to the creation of bindings.)

In my case, I just can't ever seem to get the standard (GCC) libraries working with the special (DMC) libraries with for instance OpenGL etc. ?

There are no real source changes, beyond that DMD uses "linux" and GDC uses "Unix" and that GDC is of an older DMD (language) specification.

--anders

Anders F Björklund wrote:
> Bruno Medeiros wrote:
>>> A recent post included more modern/open source versions of the headers,
>>> built from Mesa OpenGL and FreeGLUT instead of "my" SGI OpenGL and GLUT.
>>>
>>> http://www.digitalmars.com/d/archives/digitalmars/D/announce/2982.html
>>
>> *Sigh*, yes, another binding to the mix. Like you said it seems similar to Derelict, except it is based on different GL headers?
> 
> It's similar to the ones above, in that is based on a port of C headers.
> (seems to include more headers though, including the "platform" GL ones)
> 
> Derelict is based on a different idea, namely loading function pointers?
> 

Huh? Jamie Pelcis bindings are similar to Derelict, since they also load function pointers. You said it yourself.

>>> Basically I just include everything in sdl/*.d and link it with SDL ?
>>> (similar to how you use it from C, so it's wasn't very documented no)
>>
>> No, you *also* have to link with the SDL_D libs, right? (This is something that must be mentioned.)
> 
> The only tricky part is that Mac OS X can't use the regular SDLmain, but must use a SDLmain_d that has been patched to use a different "main" name so that the D and the Objective-C startup can co-exist nicely...
> 
> The other libraries are just a convenience that I used so that I didn't have to include all the of the source code files with every compilation.
> But you *can* do that just fine, with the regular DMD syntax: gdmd *.d
> 
> (well, at least that was the idea - maybe it was messed up in practice)
> 

gdmd? What's that about? Isn't it an old project?

In any case, you can't do "dmd *.d" on the bindings just fine (with dmd at least,haven't tried with gdc), as it fails the compilation because of the mismatched module names, which is what I'm trying to say.

>>> The other ones just had implicit names, since they're all in "sdl"...
>>
>> I know they have implicit names, I can see that myself :P
>> But it is still broke. It works *only* if you compile each module separately, *and* if you only import sdl.sdl (or sdl.main) in your application. (if you import certain other sdl modules it breaks)
>> Surely you agree this is not proper behavior.?
> 
> I do, but it worked for me when I put it in my /usr/include/d/sdl...
> But I'll add the module names at the top of each file, to "fix" it.
> 
Like I said, if I'm not mistaken, it only worked because you compiled each module separately, and because you imported only the sdl.sdl module (or sdl.main).
(And thanks for the upcoming fix.)

>>> Once I update the headers to SDL 1.2.10 (etc), I will package it up too.
>>> It will probably only work with GDC, but Derelict is good for DMD use ?
>>>
>> Whoa! "will probably only work with GDC" !?  :|
>> (And MikeP also mentioned that Derelict didn't work with GDC as of yet) 
> 
> My main target is GDC and Make. I know that others prefer DMD and Build,  which is why I suggest that other libraries might be better if you do ?
> 
> In theory all the platforms belongs the same "GNU" target interface...
> But I usually test my releases on Mac OS X, Windows XP and Fedora Core.
> 
>> Are GDC and DMD so far off from each other that it is hard to build code that works in both?! What kind of things are working differently? (I only know of 'the lack of newer D features', and 'the typeof ==/is problem', both of which don't seem very problematic to the creation of bindings.)
> 
> In my case, I just can't ever seem to get the standard (GCC) libraries working with the special (DMC) libraries with for instance OpenGL etc. ?
> 
> There are no real source changes, beyond that DMD uses "linux" and GDC uses "Unix" and that GDC is of an older DMD (language) specification.
> 
> --anders

I'm not understanding you here. What special DMC libraries? What's the relation with OpenGL? (that phrase seems a bit misconstructed)

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:

>> Derelict is based on a different idea, namely loading function pointers?
> 
> Huh? Jamie Pelcis bindings are similar to Derelict, since they also load function pointers. You said it yourself.

Oops, I must have been confused. Either way, there are two schools :-)
And I'm not really into pointers, unless they are needed (GL extensions)

> gdmd? What's that about? Isn't it an old project?

"gdmd" is a shell/script wrapper that converts the DM-style syntax into the GNU-style syntax as "gdc" expects. It's not another project/compiler

> In any case, you can't do "dmd *.d" on the bindings just fine (with dmd at least,haven't tried with gdc), as it fails the compilation because of the mismatched module names, which is what I'm trying to say.

I know, I meant to write sdl/*.d. But I will rewrite it properly...
(it's not really as confusing as I am making it sound, fortunately)

We both agree on how it should be, no use rationalizing the old hacks.
Once I have something new out, then we can start this thread over. :-)

>> In my case, I just can't ever seem to get the standard (GCC) libraries working with the special (DMC) libraries with for instance OpenGL etc. ?
>>
>> There are no real source changes, beyond that DMD uses "linux" and GDC uses "Unix" and that GDC is of an older DMD (language) specification.
> 
> I'm not understanding you here. What special DMC libraries? What's the relation with OpenGL? (that phrase seems a bit misconstructed)

They use different "lib" formats, which I believe is one of the major reasons why it is so hard to link with DLLs on Windows and why Derelict et al were born in the first place ? On Linux and Mac OS X, I can just link directly with the shared libraries - no import libraries required.

My problems with DMC was when I tried to link with OpenGL and wxWidgets,
and with the SDL libraries from the binary SDL distribution. They never seemed to work right out of the box, unless I rebuilt them from source.
Thus "special", it seems that any binaries are for a) VS or b) MinGW ?


For me coming from Unix, it's easier to just use MSYS: configure && make
But DMC/DMD and DM-Make/Build might be easier if you're used to Windows?

--anders

Anders F Björklund wrote:
> Bruno Medeiros wrote:
> [snip]
> 
> They use different "lib" formats, which I believe is one of the major reasons why it is so hard to link with DLLs on Windows and why Derelict et al were born in the first place ? On Linux and Mac OS X, I can just link directly with the shared libraries - no import libraries required.
> 
> My problems with DMC was when I tried to link with OpenGL and wxWidgets, and with the SDL libraries from the binary SDL distribution. They never seemed to work right out of the box, unless I rebuilt them from source. Thus "special", it seems that any binaries are for a) VS or b) MinGW ?
> 

The thing is that ".LIB" can mean a few things:

1. An OMF static library,
2. A COFF static library,
3. A post VC6 (I believe) COFF static library,
4. A "Whatever the hell format MS decides to use this month" static library.

The problem is that MS kept changing what format static libraries were in.  DMD uses the original OMF format, but this is problematic since most binary distributions of libraries are compiled for the "latest" static library format for MSVC, which as I said is not OMF.

In that case, you've got 2 options: try to convert the import library back to OMF (which seems to work OK most of the time), or recompile.

This is why I prefer the pure-D dynamic loading approach: the problem simply doesn't come up :)

> 
> For me coming from Unix, it's easier to just use MSYS: configure && make But DMC/DMD and DM-Make/Build might be easier if you're used to Windows?

I believe you can change which compiler build uses in the configuration files.  That said, I think the whole point of build was the remove the need for autoconf and makefiles entirely.  I know that *I've* had my share of pain from being forced to use the GNU toolchain under Windows... any tool that makes that whole damn archaic mess obsolete is gold in my book.

> 
> --anders

	-- Daniel

-- 

v1sw5+8Yhw5ln4+5pr6OFma8u6+7Lw4Tm6+7l6+7D a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP    http://hackerkey.com/

Daniel Keep wrote:

> The problem is that MS kept changing what format static libraries were
> in.  DMD uses the original OMF format, but this is problematic since
> most binary distributions of libraries are compiled for the "latest"
> static library format for MSVC, which as I said is not OMF.
> 
> In that case, you've got 2 options: try to convert the import library
> back to OMF (which seems to work OK most of the time), or recompile.
> 
> This is why I prefer the pure-D dynamic loading approach: the problem
> simply doesn't come up :)

I've found that using another operating systems also helps,
but am trying to learn the arcane skills of Win DLL linking.

I totally blame Microsoft and Visual Studio for all of it...

>>For me coming from Unix, it's easier to just use MSYS: configure && make
>>But DMC/DMD and DM-Make/Build might be easier if you're used to Windows?
> 
> I believe you can change which compiler build uses in the configuration
> files.  That said, I think the whole point of build was the remove the
> need for autoconf and makefiles entirely.  I know that *I've* had my
> share of pain from being forced to use the GNU toolchain under
> Windows... any tool that makes that whole damn archaic mess obsolete is
> gold in my book.

Swapping one pain for another, hoping that it is less ? ;-)

I know that *I* have had my share of pain trying to compile
projects hardcoded to DMD and Build under Unix or Mac OS X...

--anders

Bruno Medeiros wrote:
> Ant wrote:
> 
>> Bruno Medeiros wrote:
>>
>>> My slightly ranty topic about the current state of SDL* and GL bindings.
>>
>>
>>
>> should I post a reply? should I?
>>
>> no, better not...
>>
>> Ant
> 
> 
> Huh...?
> Did I post something wrong or inappropriate?
> 

I don't get it either...

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M--@ V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne

Mike Parker wrote:
> Bruno Medeiros wrote:
> 
>>
>> But since dll's are usually packaged with the game/app itself, isn't a missing dll something so rare that it is exaggerated to worry about it so much? How can it happen at all, it seems so far-fetched.
> 
> That's true for things like SDL and such, but not OpenGL. Sometimes downloads become corrupted, installations get borked, people delete files by accident... there are a lot of variables.
> 
> When Herb Marselas was still with Ensemble Studios he wrote an article for Game Programming Gems 2 called "Protect Yourself From DLL Hell and Missing OS Functions" in which he advocated even loading Win32 API DLLs manually. I'm not sure I'd go that far, as there are other applications that would likely barf before a game would. But his reasoning in the article was sound.
> 

The only time I can recall that an app unexpectedly didn't load a dll, was for some of the MSVC runtime libs. So following your reasoning, you should load these libs dynamically too.. *g* :P

> 
>>
>> Wouldn't a pure header conversion work in all platforms that the original header works in?...
>> It doesn't work on Mac, and it didn't work before in Linux because you need to add the code to the dynamic binding, right?
> 
> Right. But then that would defeat the purpose of Derelict. Again, the other bindings already link to the import library statically. Derelict is meant to provide an alternative.
> 
>>
>>>
>>> For what it's worth, one of the future additions to Derelict is going to be the ability to link statically with an import library and bypass the runtime loading mechanism. 
>>
>> That would be great!
> 
> I'm glad you think so, but I still don't understand why. I flip-flopped on this for a long time, because it means double the effort and I just don't see the benefit of it versus the current mechanism. Manual loading is much more flexible, which to me equates to "better". I can't see any benefit at all to linking statically to the import libraries, other than 

Well, if dynamic loading supports all platforms that static loading, then there really isn't much difference. But as we know, that is not the case. ;p


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Mike Parker wrote:

> 
> Well, if dynamic loading supports all platforms that static loading, then there really isn't much difference. But as we know, that is not the case. ;p

Ah, not true. Dynamic loading is possible on all the platforms that D currently has been ported to. Derelict just doesn't support them all yet ;).

Anders F Björklund wrote:
> Bruno Medeiros wrote:
> 
>>> Derelict is based on a different idea, namely loading function pointers?
>>
>> Huh? Jamie Pelcis bindings are similar to Derelict, since they also load function pointers. You said it yourself.
> 
> Oops, I must have been confused. Either way, there are two schools :-)
> And I'm not really into pointers, unless they are needed (GL extensions)
> 
>> gdmd? What's that about? Isn't it an old project?
> 
> "gdmd" is a shell/script wrapper that converts the DM-style syntax into the GNU-style syntax as "gdc" expects. It's not another project/compiler
> 

I was thinking gdmd was this (an old D compiler):
http://www.digitalmars.com/d/archives/D/gnu/462.html
Only now have I realized that this was GDC's previous name, right?


>> In any case, you can't do "dmd *.d" on the bindings just fine (with dmd at least,haven't tried with gdc), as it fails the compilation because of the mismatched module names, which is what I'm trying to say.
> 
> I know, I meant to write sdl/*.d. But I will rewrite it properly...
> (it's not really as confusing as I am making it sound, fortunately)
> 

It is the same, with "sdl/*.d" it will still not compile due to module conflicts.

> We both agree on how it should be, no use rationalizing the old hacks.
> Once I have something new out, then we can start this thread over. :-)
> 

Ok. ;)

>>> In my case, I just can't ever seem to get the standard (GCC) libraries working with the special (DMC) libraries with for instance OpenGL etc. ?
>>>
>>> There are no real source changes, beyond that DMD uses "linux" and GDC uses "Unix" and that GDC is of an older DMD (language) specification.
>>
>> I'm not understanding you here. What special DMC libraries? What's the relation with OpenGL? (that phrase seems a bit misconstructed)
> 
> They use different "lib" formats, which I believe is one of the major reasons why it is so hard to link with DLLs on Windows and why Derelict et al were born in the first place ? On Linux and Mac OS X, I can just link directly with the shared libraries - no import libraries required.
> 
> My problems with DMC was when I tried to link with OpenGL and wxWidgets,
> and with the SDL libraries from the binary SDL distribution. They never seemed to work right out of the box, unless I rebuilt them from source.
> Thus "special", it seems that any binaries are for a) VS or b) MinGW ?
> 

Yes, they use different "lib" formats, and to link successfully you have to rebuild the .lib with DMC from the sources, or, more easily, you now have the "coffimplib" tool that does that work:
http://www.digitalmars.com/d/archives/c++/announce/864.html

But what has this to do with the compatibility of the D bindings themselves? Seems to me it doesn't affect it at all.

> 
> For me coming from Unix, it's easier to just use MSYS: configure && make
> But DMC/DMD and DM-Make/Build might be easier if you're used to Windows?
> 
> --anders

I think Build is easier in *any* platform.
Also, I use Windows, but I have MSYS installed and use it often. In fact, in the semester that I had some C++ projects, I used mingw's GCC (plus Eclipse CDT) more often than MS VC++.
In any case this is all besides the point.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Mike Parker wrote:
> Bruno Medeiros wrote:
>> Mike Parker wrote:
> 
>>
>> Well, if dynamic loading supports all platforms that static loading, then there really isn't much difference. But as we know, that is not the case. ;p
> 
> Ah, not true. Dynamic loading is possible on all the platforms that D currently has been ported to. Derelict just doesn't support them all yet ;).

Yes, I know. That "if" was a "when" kind of "if" :P

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D