(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

"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.

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
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.
>
>

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

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

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.

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

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.