Don Clugston wrote:

> I have a grandiose scheme for a C2D project, where rather than storing the converted headers (with associated licensing issues), we instead store the 'script' (actually more of a hint file) that was used for conversion.

Arguably, if those "scripts" are verbose enough they could be
subject to the very same licensing issues as the header files... :-(

But it would be neat to have for the old Mac OS headers (i.e. Carbon),
in addition to the full Win32 SDK headers that I gather you're doing.

> It would be fantastic to accumulate a database of C2D files.

Or have a better tool ? I guess you've looked at SWIG, by the way ?

> Sample C2D script format (excerpt of part of the one that converts the Win SDK headers). There are a few other sections, apart from those shown here. The C2D program can't do the full Win SDK yet (I'm currently working out what to do with bitfields in structs), but it's OK for fairly simple headers right now.

Bitfields usually means writing wrapper accessors/mutators...
But I guess that would be a bit hard to do automated, right ?

The Perl hack I used is at http://www.algonet.se/~afb/d/h2d.pl
It doesn't preprocess and it doesn't parse. It just replaces...

But I've successfully used it for "step one" in translating.

--anders

Anders F Björklund wrote:
> Don Clugston wrote:
> 
>> I have a grandiose scheme for a C2D project, where rather than storing the converted headers (with associated licensing issues), we instead store the 'script' (actually more of a hint file) that was used for conversion.
> 
> Arguably, if those "scripts" are verbose enough they could be
> subject to the very same licensing issues as the header files... :-(

I guess that's possible, but they'll have very little information in them. Typically, just the names of a couple of the #defines, most of which are listed in external documentation, and which are used in samples. It's not a problem for the Windows SDK, because the MingW header script seems to work with the Microsoft files, too. I'm not sure about Carbon, though.
In any case, it will be clear that the source is not being redistributed.

Actually, though, my primary intention is to be able to keep up with open-source header changes, rather than avoid the license issues.

> But it would be neat to have for the old Mac OS headers (i.e. Carbon),
> in addition to the full Win32 SDK headers that I gather you're doing.

>> It would be fantastic to accumulate a database of C2D files.
> 
> Or have a better tool ? I guess you've looked at SWIG, by the way ?

Yes, it would be good to leverage off something else. Unfortunately, it seems that SWIG requires you to modify the header file. It would definitely be the way to go for C++ code, though.

>> Sample C2D script format (excerpt of part of the one that converts the Win SDK headers). There are a few other sections, apart from those shown here. The C2D program can't do the full Win SDK yet (I'm currently working out what to do with bitfields in structs), but it's OK for fairly simple headers right now.
> 
> Bitfields usually means writing wrapper accessors/mutators...
> But I guess that would be a bit hard to do automated, right ?

It's tricky, but possible. I might just cheat and require them to be defined manually for now.

> The Perl hack I used is at http://www.algonet.se/~afb/d/h2d.pl
> It doesn't preprocess and it doesn't parse. It just replaces...

C isn't too difficult to parse, fortunately. And _perfect_ parsing doesn't seem to be necessary (there's a huge advantage in knowing that the code is valid C).

Would derivative works still be under the same non-redistributable license?  If so, there is no point in porting it.

Anders F Björklund wrote:
> And that is the problem. Without a Mac, you don't have the original headers and they can't be-redistributed without permission from Apple...

Keeping up with the changes isn't normally a big deal (although there are exceptions).  It's getting it done the first time.

Don Clugston wrote:
> Actually, though, my primary intention is to be able to keep up with open-source header changes, rather than avoid the license issues.

Fortunately many of the larger projects attempt to make their headers as simple as possible to make sure all compilers will treat it the same.  A problem may arise from different conventions on how to make code look good though.

> C isn't too difficult to parse, fortunately. And _perfect_ parsing doesn't seem to be necessary (there's a huge advantage in knowing that the code is valid C).

That makes it all worth it!

Anders F Björklund wrote:
> But I've successfully used it for "step one" in translating.

If http://darcs.brianweb.net/vendor/powerpc-apple-darwin/include/ is legal, then so is a port of AGL.  The updated version on the website should have most of it, but I had trouble finding the information on Style.  Would someone with a Mac (hi Anders) please test it?  Thank you!

James Pelcis wrote:
> Would derivative works still be under the same non-redistributable license?  If so, there is no point in porting it.
> 
> Anders F Björklund wrote:
>> And that is the problem. Without a Mac, you don't have the original headers and they can't be-redistributed without permission from Apple...

James Pelcis wrote:

> If http://darcs.brianweb.net/vendor/powerpc-apple-darwin/include/ is legal, then so is a port of AGL. 

Yeah, so that only leaves the question: is it ? :-)

> The updated version on the website should have most of it, but I had trouble finding the information on Style.  Would someone with a Mac (hi Anders) please test it?  Thank you!

Hmm, not sure how I would test it without the rest of Carbon ?
But maybe I can use my old hello world to get an AGL window up...

Anyway, here are two bugs meanwhile:

c/gl/glext.d:2868: glTexCoord2fColor4fNormal3fVertex3fSUN is used as a type
c/gl/glext.d:2868: variable c.gl.glext._staticCtor.glTexCoord2fColor4fNormal3fVertex3fSUN voids have no value
c/gl/glext.d:2869: cannot implicitly convert expression (cast(void(C *)(float, float, float, float, float, float, float, float, float, float, float, float))(getProc("glTexCoord2fColor4fNormal3fVertex3fSUN"))) of type pfglTexCoord2fColor4fNormal3fVertex3fSUN to int

c/gl/glext.d:3308: glGetFramebufferAttachmentParameterivEXT is used as a type
c/gl/glext.d:3308: variable c.gl.glext._staticCtor.glGetFramebufferAttachmentParameterivEXT voids have no value
c/gl/glext.d:3309: cannot implicitly convert expression (cast(void(C *)(uint, uint, uint, int*))(getProc("glGetFramebufferAttachmentParameterivEXT"))) of type pfglGetFramebufferAttachmentParameterivEXT to int

You'll notice I had to move all the D sources, before it compiled...
(they are supposed to go in a c/gl subdirectory, to match the module)

--anders

James Pelcis wrote:

> but I had trouble finding the information on Style.

That would be an oldskool Mac type:

// Quickdraw font rendering styles
alias ubyte Style;
alias short StyleParameter;
alias Style StyleField;

Part of <CarbonCore/MacTypes.h>

--anders

James Pelcis wrote:

> Would someone with a Mac (hi Anders) please test it?  Thank you!

Also, there was a (C) declaration missed on the glut fonts:

ld: Undefined symbols:
__D1c2gl4glut15glutBitmap8By13Pv
__D1c2gl4glut15glutBitmap9By15Pv
__D1c2gl4glut15glutStrokeRomanPv
__D1c2gl4glut19glutStrokeMonoRomanPv
__D1c2gl4glut21glutBitmapHelvetica10Pv
__D1c2gl4glut21glutBitmapHelvetica12Pv
__D1c2gl4glut21glutBitmapHelvetica18Pv
__D1c2gl4glut22glutBitmapTimesRoman10Pv
__D1c2gl4glut22glutBitmapTimesRoman24Pv

Should be declared like this:

	extern (C) GLvoid* glutStrokeRoman;

Otherwise they get D mangling.


You can't declare them in the D import module either,
since then it won't link to the external ones from C ?

i.e. they should go into a separate "glutextern.d" file

--anders


PS.
Doesn't seem to start, though:
Error: circular initialization dependency with module gl
Not sure what that is all about.

Thanks for the help.  I think everything works.  The glext errors were caused by the partial failure of a regex.  I think everything works, but it would be nice if you could get that "Hello World" in AGL.

Anders F Björklund wrote:
> James Pelcis wrote:
> 
>> If http://darcs.brianweb.net/vendor/powerpc-apple-darwin/include/ is legal, then so is a port of AGL. 
> 
> Yeah, so that only leaves the question: is it ? :-)
> 
>> The updated version on the website should have most of it, but I had trouble finding the information on Style.  Would someone with a Mac (hi Anders) please test it?  Thank you!
> 
> Hmm, not sure how I would test it without the rest of Carbon ?
> But maybe I can use my old hello world to get an AGL window up...
> 
> Anyway, here are two bugs meanwhile:
> 
> c/gl/glext.d:2868: glTexCoord2fColor4fNormal3fVertex3fSUN is used as a type
> c/gl/glext.d:2868: variable c.gl.glext._staticCtor.glTexCoord2fColor4fNormal3fVertex3fSUN voids have no value
> c/gl/glext.d:2869: cannot implicitly convert expression (cast(void(C *)(float, float, float, float, float, float, float, float, float, float, float, float))(getProc("glTexCoord2fColor4fNormal3fVertex3fSUN"))) of type pfglTexCoord2fColor4fNormal3fVertex3fSUN to int
> 
> c/gl/glext.d:3308: glGetFramebufferAttachmentParameterivEXT is used as a type
> c/gl/glext.d:3308: variable c.gl.glext._staticCtor.glGetFramebufferAttachmentParameterivEXT voids have no value
> c/gl/glext.d:3309: cannot implicitly convert expression (cast(void(C *)(uint, uint, uint, int*))(getProc("glGetFramebufferAttachmentParameterivEXT"))) of type pfglGetFramebufferAttachmentParameterivEXT to int
> 
> You'll notice I had to move all the D sources, before it compiled...
> (they are supposed to go in a c/gl subdirectory, to match the module)
> 
> --anders