www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - version not working with extern(Windows) on linux

reply hellcatv hotmail.com writes:
I am porting a few C header files to D, and I'm finding it difficult to get the
versioning working.

specifically, I want to be able to use the same .d file for both windows and
linux

extern (C) {
extern (Windows) {
export void test ();
}
}
this works in windows, and in linux--but it relies on the fact that
extern(Windows) does NOT do anything
a more portable way does NOT work
extern(C) {
export version(Windows){extern (Windows)} void test();
}
the above fails to link in windows though both work in linux
this is using gdc in linux and dmc in windows

any suggestions as to how to get the version to work with the extern (Windows)
command...I want to share a header between the two OS's for ease of use
May 04 2004
parent reply "Walter" <newshound digitalmars.com> writes:
Why use extern (Windows) at all in portable code?

<hellcatv hotmail.com> wrote in message
news:c77jqd$29em$1 digitaldaemon.com...

 I am porting a few C header files to D, and I'm finding it difficult to


get the

 versioning working.

 specifically, I want to be able to use the same .d file for both windows


and

 linux

 extern (C) {
 extern (Windows) {
 export void test ();
 }
 }
 this works in windows, and in linux--but it relies on the fact that
 extern(Windows) does NOT do anything
 a more portable way does NOT work
 extern(C) {
 export version(Windows){extern (Windows)} void test();
 }
 the above fails to link in windows though both work in linux
 this is using gdc in linux and dmc in windows

 any suggestions as to how to get the version to work with the extern


(Windows)

 command...I want to share a header between the two OS's for ease of use
May 04 2004
parent reply Daniel Horn <hellcatv hotmail.com> writes:
I'm trying to link in opengl32.dll and glut32.dll
so I need to create a gl.d (to replace gl.h) and glut.d (to replace 
glut.h), preferably a gl.d that I can share between linux and windows.

Right now it works, but I am using extern(Windows){ at the top

I could fool the linker by making a specially hacked glut32.def and 
opengl32.def file to alias the extern(C) type exports to the ones 
defined in the dll--is this the preferred method? It seems like changing 
the calling convention to keep cross-platform is not necessarily a good idea

ideally we COULD have a single header file that would serve both linux 
.so and windows .dll's much like gl.h does today
i.e. I think version should also be able to #ifdef out extern(Windows)

Walter wrote:

 Why use extern (Windows) at all in portable code?
 
 <hellcatv hotmail.com> wrote in message
 news:c77jqd$29em$1 digitaldaemon.com...
 

I am porting a few C header files to D, and I'm finding it difficult to


 
 get the
 

versioning working.

specifically, I want to be able to use the same .d file for both windows


 
 and
 

linux

extern (C) {
extern (Windows) {
export void test ();
}
}
this works in windows, and in linux--but it relies on the fact that
extern(Windows) does NOT do anything
a more portable way does NOT work
extern(C) {
export version(Windows){extern (Windows)} void test();
}
the above fails to link in windows though both work in linux
this is using gdc in linux and dmc in windows

any suggestions as to how to get the version to work with the extern


 
 (Windows)
 

command...I want to share a header between the two OS's for ease of use
May 04 2004
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Daniel Horn wrote:

 I'm trying to link in opengl32.dll and glut32.dll
 so I need to create a gl.d (to replace gl.h) and glut.d (to replace 
 glut.h), preferably a gl.d that I can share between linux and windows.
 
 Right now it works, but I am using extern(Windows){ at the top
 
 I could fool the linker by making a specially hacked glut32.def and 
 opengl32.def file to alias the extern(C) type exports to the ones 
 defined in the dll--is this the preferred method? It seems like changing 
 the calling convention to keep cross-platform is not necessarily a good 
 idea
 
 ideally we COULD have a single header file that would serve both linux 
 .so and windows .dll's much like gl.h does today
 i.e. I think version should also be able to #ifdef out extern(Windows)


This should get you where you want to be:

version (Win32) {
     extern (Windows):
} else {
     extern (C):
}

void glThingie(...); // this will be extern (Windows) on win32, else
                      // extern(C)
void glOtherThingie(...);
// et cetera

  -- andy
May 04 2004
parent reply David Tiktin <dtiktin nospam.totally-bogus.com> writes:
On 04 May 2004, Andy Friesen <andy ikagames.com> wrote:


 This should get you where you want to be:
 
 version (Win32) {
      extern (Windows):
 } else {
      extern (C):
 }
 
 void glThingie(...); // this will be extern (Windows) on win32,else 
                       // extern(C)
 void glOtherThingie(...);
 // et cetera


Great!  I had the same problem and your solution works.  But I'm new to 
D, and I'm not clear about the syntax with a colon.  Does the effect 
just continue to then end of the source file?  Can you give a reference 
to where this is explained?

Dave

-- 
D.a.v.i.d  T.i.k.t.i.n
t.i.k.t.i.n [at] a.d.v.a.n.c.e.d.r.e.l.a.y [dot] c.o.m
Jul 08 2004
parent Ben Hinkle <bhinkle4 juno.com> writes:
David Tiktin wrote:


 On 04 May 2004, Andy Friesen <andy ikagames.com> wrote:
 

 This should get you where you want to be:
 
 version (Win32) {
      extern (Windows):
 } else {
      extern (C):
 }
 
 void glThingie(...); // this will be extern (Windows) on win32,else
                       // extern(C)
 void glOtherThingie(...);
 // et cetera


 
 Great!  I had the same problem and your solution works.  But I'm new to
 D, and I'm not clear about the syntax with a colon.  Does the effect
 just continue to then end of the source file?  Can you give a reference
 to where this is explained?
 
 Dave
 


see http://www.digitalmars.com/d/attribute.html where it says
 attribute:           affects all declarations until the next }
    declaration;
    declaration;
    ...

(or I guess until the end of the file)
Jul 08 2004
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Daniel Horn" <hellcatv hotmail.com> wrote in message
news:c78n8f$tgg$1 digitaldaemon.com...

 I'm trying to link in opengl32.dll and glut32.dll
 so I need to create a gl.d (to replace gl.h) and glut.d (to replace
 glut.h), preferably a gl.d that I can share between linux and windows.

 Right now it works, but I am using extern(Windows){ at the top

 I could fool the linker by making a specially hacked glut32.def and
 opengl32.def file to alias the extern(C) type exports to the ones
 defined in the dll--is this the preferred method?


That will not work, because the linker cannot change the calling convention.


 It seems like changing
 the calling convention to keep cross-platform is not necessarily a good


idea

 ideally we COULD have a single header file that would serve both linux
 .so and windows .dll's much like gl.h does today
 i.e. I think version should also be able to #ifdef out extern(Windows)


I think the easiest way to make this work is just cut and paste the
declarations:

version (Windows)
{
    extern (Windows):
        declarations...
}
else
{
    extern (C)
        declarations...
}
May 04 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:
  > I think the easiest way to make this work is just cut and paste the

 declarations:
 
 version (Windows)
 {
     extern (Windows):
         declarations...
 }
 else
 {
     extern (C)
         declarations...
 }
 


I think copying code is the worst thing you could do. This kind of stuff 
can quickly become a maintenance nightmare. The whole point of 
conditional compilation is to have the same piece of code work in 
different environments, so that you will NOT have to manually copy all 
changes to all targets (and inevitably forget some).

Otherwise you could just as well create different source files for each 
version and only compile the one you want.

Just an idea, but does/could alias work for such situations? Like:

version(Windows)
	alias extern(Windows) extern(MyConvention);
else
	alias extern(C) extern(MyConvention);

extern(MyConvention):
	...


However, my guess is that version will need to become more powerful 
anyway. There is a lot of conditional compilation stuff that just isn't 
possible in D right now. Especially boolean expressions among version 
parameters (i.e. version( a || b && !c) are a must have, IMHO.


Hauke
May 04 2004
parent "Walter" <newshound digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:c795fn$1kp2$1 digitaldaemon.com...

 Walter wrote:
   > I think the easiest way to make this work is just cut and paste the

 declarations:


 I think copying code is the worst thing you could do. This kind of stuff
 can quickly become a maintenance nightmare. The whole point of
 conditional compilation is to have the same piece of code work in
 different environments, so that you will NOT have to manually copy all
 changes to all targets (and inevitably forget some).


Significantly mitigating that is the block can be copied en masse, the
extern statement does not have to be added line by line as it would in C++.


 Otherwise you could just as well create different source files for each
 version and only compile the one you want.


What I don't really understand is why even use the Windows calling
convention for newly written C code. It offers nothing beyond uglification
of the C source.


 Just an idea, but does/could alias work for such situations? Like:

 version(Windows)
 alias extern(Windows) extern(MyConvention);
 else
 alias extern(C) extern(MyConvention);

 extern(MyConvention):
 ...


That syntactically can work, but it's something I'd rather avoid.


 However, my guess is that version will need to become more powerful
 anyway. There is a lot of conditional compilation stuff that just isn't
 possible in D right now. Especially boolean expressions among version
 parameters (i.e. version( a || b && !c) are a must have, IMHO.


I'm familiar with a lot of uses of expressions for conditional compilation,
including using it myself, and over the years I began to suspect it was way
overused. Instead, an identifier should be created for each 'feature' one
wants to use.

Then, && is:
    version (Foo) version (Bar) version=Feature;
|| is:
    version (Foo) version=Feature;
    version (Bar) version=Feature;
and ! is:
    version (Foo) { } else version=Feature;
Jul 08 2004
prev sibling parent Daniel Horn <hellcatv hotmail.com> writes:
pasting the function definitions twice?? that's so much bloat!
that means double the work every time a new EXT extension gets 
added...sure I could write a script--but it's messy and it would be nice 
if a mechanism existed to automate the procedure

or how about defining that extern(Windows) does something "right" in 
linux :-) (it seems to work properly with extern(Windows) for both linux 
and windows..but given that it's not in the spec I hesitate to ship 
something with it)

Walter wrote:

 "Daniel Horn" <hellcatv hotmail.com> wrote in message
 news:c78n8f$tgg$1 digitaldaemon.com...
 

I'm trying to link in opengl32.dll and glut32.dll
so I need to create a gl.d (to replace gl.h) and glut.d (to replace
glut.h), preferably a gl.d that I can share between linux and windows.

Right now it works, but I am using extern(Windows){ at the top

I could fool the linker by making a specially hacked glut32.def and
opengl32.def file to alias the extern(C) type exports to the ones
defined in the dll--is this the preferred method?


 
 
 That will not work, because the linker cannot change the calling convention.
 
 

It seems like changing
the calling convention to keep cross-platform is not necessarily a good


 
 idea
 

ideally we COULD have a single header file that would serve both linux
.so and windows .dll's much like gl.h does today
i.e. I think version should also be able to #ifdef out extern(Windows)


 
 
 I think the easiest way to make this work is just cut and paste the
 declarations:
 
 version (Windows)
 {
     extern (Windows):
         declarations...
 }
 else
 {
     extern (C)
         declarations...
 }
May 04 2004
prev sibling parent reply mike parker <mike aldacron.com> writes:
Daniel Horn wrote:


 I'm trying to link in opengl32.dll and glut32.dll
 so I need to create a gl.d (to replace gl.h) and glut.d (to replace 
 glut.h), preferably a gl.d that I can share between linux and windows.
 
 Right now it works, but I am using extern(Windows){ at the top
 
 I could fool the linker by making a specially hacked glut32.def and 
 opengl32.def file to alias the extern(C) type exports to the ones 
 defined in the dll--is this the preferred method? It seems like changing 
 the calling convention to keep cross-platform is not necessarily a good 
 idea
 
 ideally we COULD have a single header file that would serve both linux 
 .so and windows .dll's much like gl.h does today
 i.e. I think version should also be able to #ifdef out extern(Windows)


For what it's worth, I am at this very moment working on some openGL 
modules which load the library dynamically. There are separate modules 
for each OGL version (gl11.d, ..., gl15.d), and a primary gl.d which 
publicly imports the other modules and handles the loading. Where a full 
implementation of a version is not implemented (via extensions or 
otherwise), the supported subset is loaded as extensions. I should be 
finished very soon and will post the modules on the NG when I am.
May 05 2004
parent reply hellcatv hotmail.com writes:
wow that's really cool
I was working on the same thing
I was only going to do version 1.1 and then force the user to dynamically grab
teh extension functions with the glGetProcAddress (i wrote a wrapper around the
lin and win versions)

but having the program dynamically load the proper extensions as needed (and
perhaps throw an exception in the event of a missing extension) would probably
be better...
I can 
To see my work-in-progress check out
http://graphics.stanford.edu/~danielrh/d/

it compiles and runs a glut test app on both win and lin :-)
--Daniel

PS:I haven't tried to call an extension function yet
In article <c79me1$2cvi$1 digitaldaemon.com>, mike parker says...

Daniel Horn wrote:


 I'm trying to link in opengl32.dll and glut32.dll
 so I need to create a gl.d (to replace gl.h) and glut.d (to replace 
 glut.h), preferably a gl.d that I can share between linux and windows.
 
 Right now it works, but I am using extern(Windows){ at the top
 
 I could fool the linker by making a specially hacked glut32.def and 
 opengl32.def file to alias the extern(C) type exports to the ones 
 defined in the dll--is this the preferred method? It seems like changing 
 the calling convention to keep cross-platform is not necessarily a good 
 idea
 
 ideally we COULD have a single header file that would serve both linux 
 .so and windows .dll's much like gl.h does today
 i.e. I think version should also be able to #ifdef out extern(Windows)


For what it's worth, I am at this very moment working on some openGL 
modules which load the library dynamically. There are separate modules 
for each OGL version (gl11.d, ..., gl15.d), and a primary gl.d which 
publicly imports the other modules and handles the loading. Where a full 
implementation of a version is not implemented (via extensions or 
otherwise), the supported subset is loaded as extensions. I should be 
finished very soon and will post the modules on the NG when I am.
May 04 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
hellcatv hotmail.com wrote:


wow that's really cool
I was working on the same thing
I was only going to do version 1.1 and then force the user to dynamically grab
teh extension functions with the glGetProcAddress (i wrote a wrapper around the
lin and win versions)

but having the program dynamically load the proper extensions as needed (and
perhaps throw an exception in the event of a missing extension) would probably
be better...
I can 
To see my work-in-progress check out
http://graphics.stanford.edu/~danielrh/d/
  


If your talking about openGL extensions.  I ported GLee which supports 
over 300 opengl extensions.

-- 
-Anderson: http://badmama.com.au/~anderson/
May 04 2004