D - A few questions
- Helmut Leitner <helmut.leitner chello.at> Mar 31 2003
- "Walter" <walter digitalmars.com> Mar 31 2003
- "Matthew Wilson" <dmd synesis.com.au> Mar 31 2003
- Helmut Leitner <helmut.leitner chello.at> Mar 31 2003
- Helmut Leitner <leitner hls.via.at> Apr 01 2003
- Burton Radons <loth users.sourceforge.net> Apr 01 2003
- Helmut Leitner <leitner hls.via.at> Apr 01 2003
- Burton Radons <loth users.sourceforge.net> Apr 02 2003
(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
"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
"Matthew Wilson" <dmd synesis.com.au> 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
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
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
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
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
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