Win32 + OpenGL bindings

[Jacob Carlborg]

On 2013-04-21 17:20, Diggory wrote:
> OK, thanks I think I've got the hang of the way linking works now - I
> was confused about how some things didn't seem to require libs to work,
> but now I see it's because those things were compiled into
> "druntime.lib" which was compiled into "phobos.lib".
>
> So is this correct, assuming I'm only talking about non-COFF libs:
> - D code can link directly to normal C libs

Yes.

> - .libs generated by DMD are a superset of normal C .libs, they can
> contain normal C functions but DMD also has some way of representing
> more complicated D constructs inside the .lib file (but not templates).

Yes and no. DMD produces the same .lib files as any C compiler does. The 
differences is that D functions uses mangled names this is to support 
overloaded function (two or more functions with the same name but 
different argument types), methods and template functions.

> - druntime.lib is linked into phobos.lib so only phobos.lib needs to be
> linked and the compiler does this automatically (how does this work, is
> just hard-coded in?)

Yes, druntime is included in Phobos. The compiler hard codes this (at 
least on Posix), add the -v flag when compiling and look at the end of 
the output to see the linker command it uses. There's also the dm.ini 
(dmd.conf on Posix) that contains a couple of default flags. You'll see 
that it adds the search path where Phobos is located.

> Is there a compiler independent way to tell the linker to automatically
> link in a specific library from within a .d file? (preferable this hint
> should still exist in the .di file generated from that .d file, and be
> transitive so dependencies automatically get linked in just by
> "import"ing the required stuff) If not can I suggest this as a feature?

Yes, pragma(lib, ...); but it won't work for .di files.

http://d.puremagic.com/issues/show_bug.cgi?id=2776

> I've switched to using the "head" revision in the repo and building from
> source which was surprisingly easy (thanks whoever set that up!) so now
> I can just add missing functions to windows.d as I need and rebuild and
> no more linker errors!
>
> Am I correct in thinking there is no specific order in the contents of
> windows.d? I've rearranged mine so that functions are ordered by module
> then header file so I can more easily see if a function already exists,
> and if not where to add it. Would these changes be of any use?

In general declarations are order independent. When you start with 
nested functions and static-ifs it become order dependent.

-- 
/Jacob Carlborg