www.digitalmars.com         C & C++   DMDScript  

D - A few questions

reply Helmut Leitner <helmut.leitner chello.at> writes:
(1) I found two windows.d modules:
      - a part of Phobos (50 K)
      - a rather complete Win32 API interface by Pavel 
    How are they meant to interact?
    Does it make sense to have these identically named modules?

(2) import seems to be modeled after the Java so that
       "c.stdio" translates to ROOT\c\stdio.d  
    How can modules from other arbitrary paths be included?

    What is the rationale of not allowing someone of these
       import c\stdio;
       import c/stdio;
       import d:\mylib\xyz;
       import c:\dmd\src\phobos c\stdio;
    or anything like that to allow whatever path a programmer 
    prefers?

(3) When I do an
       import c.stdio;
    the source file c\stdio.d is read.

    So I really have to supply the source?
    Why isn't the compiled objectfile enough?
    What if I just want to deliver a library without
    the module sources?

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
Mar 31 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3E889DFF.941BFED6 chello.at...
 (1) I found two windows.d modules:
       - a part of Phobos (50 K)
       - a rather complete Win32 API interface by Pavel
     How are they meant to interact?
     Does it make sense to have these identically named modules?

Use one or the other. They should be merged into one.
 (2) import seems to be modeled after the Java so that
        "c.stdio" translates to ROOT\c\stdio.d
     How can modules from other arbitrary paths be included?

The -I switch can be used to set the ROOT.
     What is the rationale of not allowing someone of these
        import c\stdio;
        import c/stdio;
        import d:\mylib\xyz;
        import c:\dmd\src\phobos c\stdio;
     or anything like that to allow whatever path a programmer
     prefers?

They'll make the source code non-portable, as well as not being tokenizable.
 (3) When I do an
        import c.stdio;
     the source file c\stdio.d is read.

Yes.
     So I really have to supply the source?

Enough of it to supply the declarations you intend to use from it.
     Why isn't the compiled objectfile enough?

Because the object file is missing most of the symbolic information.
     What if I just want to deliver a library without
     the module sources?

Instead of: int foo(parameters) { ... body ... } have your released version be just: int foo(parameters); See phobos\gc.d for an example of this.
Mar 31 2003
next sibling parent "Matthew Wilson" <dmd synesis.com.au> writes:
Sorry to be a dope on this issue, and I _know_ I should have digested
Burton's reply to my earlier post on this, but maybe having something on the
D website that shows how to adapt a library source to obj+declarations would
be useful.

Of course, I could be doing my usual and shooting before researching. If
it's already there, please just give me the url, and take it as read that my
cheeks will be red. :)

"Walter" <walter digitalmars.com> wrote in message
news:b6anti$1c91$1 digitaldaemon.com...
 "Helmut Leitner" <helmut.leitner chello.at> wrote in message
 news:3E889DFF.941BFED6 chello.at...
 (1) I found two windows.d modules:
       - a part of Phobos (50 K)
       - a rather complete Win32 API interface by Pavel
     How are they meant to interact?
     Does it make sense to have these identically named modules?

Use one or the other. They should be merged into one.
 (2) import seems to be modeled after the Java so that
        "c.stdio" translates to ROOT\c\stdio.d
     How can modules from other arbitrary paths be included?

The -I switch can be used to set the ROOT.
     What is the rationale of not allowing someone of these
        import c\stdio;
        import c/stdio;
        import d:\mylib\xyz;
        import c:\dmd\src\phobos c\stdio;
     or anything like that to allow whatever path a programmer
     prefers?

They'll make the source code non-portable, as well as not being

 (3) When I do an
        import c.stdio;
     the source file c\stdio.d is read.

Yes.
     So I really have to supply the source?

Enough of it to supply the declarations you intend to use from it.
     Why isn't the compiled objectfile enough?

Because the object file is missing most of the symbolic information.
     What if I just want to deliver a library without
     the module sources?

Instead of: int foo(parameters) { ... body ... } have your released version be just: int foo(parameters); See phobos\gc.d for an example of this.

Mar 31 2003
prev sibling parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Walter wrote:
 
 "Helmut Leitner" <helmut.leitner chello.at> wrote in message
 news:3E889DFF.941BFED6 chello.at...
 (1) I found two windows.d modules:
       - a part of Phobos (50 K)
       - a rather complete Win32 API interface by Pavel
     How are they meant to interact?
     Does it make sense to have these identically named modules?

Use one or the other. They should be merged into one.
 (2) import seems to be modeled after the Java so that
        "c.stdio" translates to ROOT\c\stdio.d
     How can modules from other arbitrary paths be included?

The -I switch can be used to set the ROOT.

...to set multiple ROOTs?
     What is the rationale of not allowing someone of these
        import c\stdio;
        import c/stdio;
        import d:\mylib\xyz;
        import c:\dmd\src\phobos c\stdio;
     or anything like that to allow whatever path a programmer
     prefers?

They'll make the source code non-portable, as well as not being tokenizable.

Could a leading '.' interpreted like a leading "\" or "/" as indicator of an absolute path import .dmd.src.phobos.c.stdio solve this?
 (3) When I do an
        import c.stdio;
     the source file c\stdio.d is read.

Yes.
     So I really have to supply the source?

Enough of it to supply the declarations you intend to use from it.
     Why isn't the compiled objectfile enough?

Because the object file is missing most of the symbolic information.

Even if compiled for debug?
     What if I just want to deliver a library without
     the module sources?

Instead of: int foo(parameters) { ... body ... } have your released version be just: int foo(parameters); See phobos\gc.d for an example of this.

But that leaves as in a situation similar to C. Prepare a "header" file separate from the source. More exactly, it adds a task to the D community task list: - D2DI, a tool to create a pure interface file And it may force us to have two different files in our systems that have the same name but different content. Could there be a solution for this? Looking for "module.di" if "module.d" is not found? -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Mar 31 2003
parent Helmut Leitner <leitner hls.via.at> writes:
Helmut Leitner wrote:
     What if I just want to deliver a library without
     the module sources?

Instead of: int foo(parameters) { ... body ... } have your released version be just: int foo(parameters); See phobos\gc.d for an example of this.

But that leaves as in a situation similar to C. Prepare a "header" file separate from the source. More exactly, it adds a task to the D community task list: - D2DI, a tool to create a pure interface file And it may force us to have two different files in our systems that have the same name but different content. Could there be a solution for this? Looking for "module.di" if "module.d" is not found?

To clarify: I don't plan to produce proprietary or closed source D libraries or modules. I'm only evaluating D and I try to check which of our typical projects or products could be done in D. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Apr 01 2003
prev sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Helmut Leitner wrote:
 (3) When I do an
        import c.stdio;
     the source file c\stdio.d is read.
 
     So I really have to supply the source?
     Why isn't the compiled objectfile enough?
     What if I just want to deliver a library without
     the module sources?

You can use digc (at http://www.opend.org/dig/) for that - when it compiles libraries (with the -lib= option) it appends the stripped import files and recreates them when the library is used. The .lib file, and .dll if you gave a -shared option, is all the binaries you need to distribute.
Apr 01 2003
parent reply Helmut Leitner <leitner hls.via.at> writes:
Burton Radons wrote:
 
 Helmut Leitner wrote:
 (3) When I do an
        import c.stdio;
     the source file c\stdio.d is read.

     So I really have to supply the source?
     Why isn't the compiled objectfile enough?
     What if I just want to deliver a library without
     the module sources?

You can use digc (at http://www.opend.org/dig/) for that - when it compiles libraries (with the -lib= option) it appends the stripped import files and recreates them when the library is used. The .lib file, and .dll if you gave a -shared option, is all the binaries you need to distribute.

Is this done by dstrip, Matthew Wilson is just talking about? Does this mean that stripped module.d files become part of the library? ... and are (a) used by the dmd from within the library or (b) extracted from to library before being used by dmd ? -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Apr 01 2003
parent Burton Radons <loth users.sourceforge.net> writes:
Helmut Leitner wrote:
 
 Burton Radons wrote:
 
Helmut Leitner wrote:

(3) When I do an
       import c.stdio;
    the source file c\stdio.d is read.

    So I really have to supply the source?
    Why isn't the compiled objectfile enough?
    What if I just want to deliver a library without
    the module sources?

You can use digc (at http://www.opend.org/dig/) for that - when it compiles libraries (with the -lib= option) it appends the stripped import files and recreates them when the library is used. The .lib file, and .dll if you gave a -shared option, is all the binaries you need to distribute.

Is this done by dstrip, Matthew Wilson is just talking about?

It's not a separate utility, just a small module in digc.
 Does this mean that stripped module.d files become part of the
 library?

Yup.
 ... and are
   (a) used by the dmd from within the library or
   (b) extracted from to library before being used by dmd
 ?

digc maintains a dictionary of libraries in \dmd\lib and updates it with the import statements that should match. When compiling code, it searches the source for matching import statements; if they exist, it drops the stripped source of the library in a temporary directory, then removes it after compilation. This is done very quickly, and the next release will double stripping speed. So DMD is completely unaware. I'll repeat my reasons why in the response to Matthew's message.
Apr 02 2003