## digitalmars.D - Local imports

• TechnoZeus (3/3) Apr 24 2005 How do you specify an include path relative to your source path
• Derek Parnell (28/30) Apr 24 2005 For example, if I had a module in "foo\" called bar.d I could do this .....
• TechnoZeus (11/41) Apr 25 2005 Ah, okay. So if I am understanding you correctly,
• Derek Parnell (13/66) Apr 25 2005 Huh? That's exactly what I do now, so I don't know why you think it won'...
• TechnoZeus (4/70) Apr 27 2005 Well, in the tests I have done, it doesn't even find the file.
• TechnoZeus (5/17) Apr 27 2005 Tried it.
• Derek Parnell (11/29) Apr 27 2005 Thank you for helping me improve the utility. Your detailed description ...
• TechnoZeus (10/39) Apr 28 2005 Unfortunately, I was needed elsewhere and had to run,
• Derek Parnell (9/21) Apr 28 2005 eg. command line, environment, source code, ... perhaps?
• TechnoZeus (37/58) Apr 29 2005 No, I've never really liked being needed.
• Derek Parnell (18/21) Apr 29 2005 And here is what I get with the same source files ...
• TechnoZeus (32/53) Apr 29 2005 No modifications to the Phobos library. (None that I didn't change back...
• Derek Parnell (11/75) Apr 29 2005 Now we're cooking...can you change the sc.ini LIB line to ...
• TechnoZeus (56/131) Apr 30 2005 Oh, that's not the problem.
• Derek Parnell (18/50) Apr 30 2005 [snip]
• TechnoZeus (85/135) May 01 2005 Ah, yes. Short on environment space here, so I didn't add dmd\bin to my...
• Derek Parnell (15/16) May 01 2005 You wouldn't happen to be running an old version of Windows, by any chan...
• TechnoZeus (26/42) May 04 2005 Yep. Running Windows 98 on this system.
• Derek Parnell (21/26) May 04 2005 Thought so. I have updated Build to cater for old Windows versions now. ...
• TechnoZeus (4/29) May 04 2005 Okay. Can't get to it right now, but when I have time, I will download ...
• TechnoZeus (4/17) May 07 2005 Was just about to run that test for you, but the dsource.org web site se...
• Derek Parnell (9/10) May 07 2005 I've made it available at my site until dsource.org is back up.
• TechnoZeus (76/86) May 07 2005 Thanks. Here goes...
• Derek Parnell (10/44) May 08 2005 Ummm, the idea was for you to try the current version of Build (v2.07) a...
• TechnoZeus (105/149) May 08 2005 Hmmm. I thought I did use the newer version.
• Derek Parnell (23/47) May 08 2005 [snip]
• TechnoZeus (28/48) May 08 2005 Yes, you would think that would work... but here's what I got testing it...
• Derek Parnell (48/79) May 08 2005
• TechnoZeus (55/133) May 09 2005 Cool. That will be great to see. Not sure how you plan to make it "
• TechnoZeus (25/25) Apr 30 2005 Derek, I was just thinking... don't know if having my system information...
• Georg Wrede (11/14) Apr 27 2005 Especially now, that we're pre-1.0, and also for the rest of the year,
• John Reimer (15/37) Apr 27 2005 "Build" is the best D utility to hit the D scene in a long time. I
• TechnoZeus (14/28) Apr 28 2005 I fully agree.
"TechnoZeus" <TechnoZeus PeoplePC.com> writes:
How do you specify an include path relative to your source path
in the sc.ini file?

TZ

Apr 24 2005
Derek Parnell <derek psych.ward> writes:
On Sun, 24 Apr 2005 18:13:37 -0500, TechnoZeus wrote:

How do you specify an include path relative to your source path
in the sc.ini file?

For example, if I had a module in "foo\" called bar.d I could do this ...

[foo\bar.d]
module bar;
int Bar2 = 3;

[test.d]
import std.stdio;
import bar;
void main()
{
writefln("%d", bar.Bar2);
}

[sc.ini]
DFLAGS="-I% P%\..\src\phobos;foo"

And the command line could either be

; To compile and link in one step
dmd test.d foo\bar.d

; To compile and link in separate steps
dmd test.d -c
dmd foo\bar.d -c
dmd test.obj bar.obj

or

build test

--
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
25/04/2005 9:40:29 AM

Apr 24 2005
"TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:h7rupvhf58kv$.1bsd5jrr8pukt$.dlg 40tude.net...
On Sun, 24 Apr 2005 18:13:37 -0500, TechnoZeus wrote:

How do you specify an include path relative to your source path
in the sc.ini file?

For example, if I had a module in "foo\" called bar.d I could do this ...

[foo\bar.d]
module bar;
int Bar2 = 3;

[test.d]
import std.stdio;
import bar;
void main()
{
writefln("%d", bar.Bar2);
}

[sc.ini]
DFLAGS="-I% P%\..\src\phobos;foo"

And the command line could either be

; To compile and link in one step
dmd test.d foo\bar.d

; To compile and link in separate steps
dmd test.d -c
dmd foo\bar.d -c
dmd test.obj bar.obj

or

build test

--
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
25/04/2005 9:40:29 AM

Ah, okay.  So if I am understanding you correctly,
it won't actually do what I was wanting it to.

I was hoping that I could set it up so that I could write
modules in the same folder as the program that
uses them, and include import lines in the program,
and then simply compile the program and let the
compiler find the modules automatically.

Oh well... it was a nice thought while it lasted.

Thanks.

TZ

Apr 25 2005
Derek Parnell <derek psych.ward> writes:
On Mon, 25 Apr 2005 03:18:53 -0500, TechnoZeus wrote:

"Derek Parnell" <derek psych.ward> wrote in message
news:h7rupvhf58kv$.1bsd5jrr8pukt$.dlg 40tude.net...
On Sun, 24 Apr 2005 18:13:37 -0500, TechnoZeus wrote:

How do you specify an include path relative to your source path
in the sc.ini file?

For example, if I had a module in "foo\" called bar.d I could do this ...

[foo\bar.d]
module bar;
int Bar2 = 3;

[test.d]
import std.stdio;
import bar;
void main()
{
writefln("%d", bar.Bar2);
}

[sc.ini]
DFLAGS="-I% P%\..\src\phobos;foo"

And the command line could either be

; To compile and link in one step
dmd test.d foo\bar.d

; To compile and link in separate steps
dmd test.d -c
dmd foo\bar.d -c
dmd test.obj bar.obj

or

build test

--
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
25/04/2005 9:40:29 AM

Ah, okay.  So if I am understanding you correctly,
it won't actually do what I was wanting it to.

I was hoping that I could set it up so that I could write
modules in the same folder as the program that
uses them, and include import lines in the program,
and then simply compile the program and let the
compiler find the modules automatically.

Oh well... it was a nice thought while it lasted.

Huh? That's exactly what I do now, so I don't know why you think it won't
work. But remember, just because you have "import xyz;" it doesn't mean
that DMD will also compile "xyz.d". If will find it when compiling the file
that contains the import though.

That's why I wrote the Build utility. I just type "Build myapp" and it
looks at import statements to see if the files they reference also need
compiling.

--
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
25/04/2005 6:51:56 PM

Apr 25 2005
"TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:b1k5xgl4lcih$.2ng5ddp5jj6q.dlg 40tude.net... On Mon, 25 Apr 2005 03:18:53 -0500, TechnoZeus wrote: "Derek Parnell" <derek psych.ward> wrote in message news:h7rupvhf58kv$.1bsd5jrr8pukt$.dlg 40tude.net... On Sun, 24 Apr 2005 18:13:37 -0500, TechnoZeus wrote: How do you specify an include path relative to your source path in the sc.ini file? For example, if I had a module in "foo\" called bar.d I could do this ... [foo\bar.d] module bar; int Bar2 = 3; [test.d] import std.stdio; import bar; void main() { writefln("%d", bar.Bar2); } [sc.ini] DFLAGS="-I% P%\..\src\phobos;foo" And the command line could either be ; To compile and link in one step dmd test.d foo\bar.d ; To compile and link in separate steps dmd test.d -c dmd foo\bar.d -c dmd test.obj bar.obj or build test -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build 25/04/2005 9:40:29 AM Ah, okay. So if I am understanding you correctly, it won't actually do what I was wanting it to. I was hoping that I could set it up so that I could write modules in the same folder as the program that uses them, and include import lines in the program, and then simply compile the program and let the compiler find the modules automatically. Oh well... it was a nice thought while it lasted. Huh? That's exactly what I do now, so I don't know why you think it won't work. But remember, just because you have "import xyz;" it doesn't mean that DMD will also compile "xyz.d". If will find it when compiling the file that contains the import though. That's why I wrote the Build utility. I just type "Build myapp" and it looks at import statements to see if the files they reference also need compiling. -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build 25/04/2005 6:51:56 PM Well, in the tests I have done, it doesn't even find the file. I'll take a look at your build utility. thanks... however, this is something that I would much rather see built into the compiler, than only available as an add-on. TZ  Apr 27 2005 "TechnoZeus" <TechnoZeus PeoplePC.com> writes:  "Derek Parnell" <derek psych.ward> wrote in message news:h7rupvhf58kv$.1bsd5jrr8pukt$.dlg 40tude.net... On Sun, 24 Apr 2005 18:13:37 -0500, TechnoZeus wrote: *snip* That's why I wrote the Build utility. I just type "Build myapp" and it looks at import statements to see if the files they reference also need compiling. -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build 25/04/2005 6:51:56 PM Tried it. All I got was... Error: Access Violation TZ  Apr 27 2005 Derek Parnell <derek psych.ward> writes: On Wed, 27 Apr 2005 10:53:40 -0500, TechnoZeus wrote: "Derek Parnell" <derek psych.ward> wrote in message news:h7rupvhf58kv$.1bsd5jrr8pukt$.dlg 40tude.net... On Sun, 24 Apr 2005 18:13:37 -0500, TechnoZeus wrote: *snip* That's why I wrote the Build utility. I just type "Build myapp" and it looks at import statements to see if the files they reference also need compiling. -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build 25/04/2005 6:51:56 PM Tried it. All I got was... Error: Access Violation Thank you for helping me improve the utility. Your detailed description of the situation and how you used the product was most insightful. I especially appreciated the display of the 'verbose' run that enabled me to track down my mistake. I hope you are aware of how fortunate you must be, as that you are the first to report this error. I imagine that this warrants a special treat. -- Derek Parnell Melbourne, Australia 28/04/2005 2:15:06 AM  Apr 27 2005 "TechnoZeus" <TechnoZeus PeoplePC.com> writes: "Derek Parnell" <derek psych.ward> wrote in message news:ngq27pajdpph.1li2r5ozedhlw$.dlg 40tude.net...
On Wed, 27 Apr 2005 10:53:40 -0500, TechnoZeus wrote:

"Derek Parnell" <derek psych.ward> wrote in message
news:h7rupvhf58kv$.1bsd5jrr8pukt$.dlg 40tude.net...
On Sun, 24 Apr 2005 18:13:37 -0500, TechnoZeus wrote:

*snip*
That's why I wrote the Build utility. I just type "Build myapp" and it
looks at import statements to see if the files they reference also need
compiling.

--
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
25/04/2005 6:51:56 PM

Tried it.
All I got was...
Error: Access Violation

Thank you for helping me improve the utility. Your detailed description of
the situation and how you used the product was most insightful. I
especially appreciated the display of the 'verbose' run that enabled me to
track down my mistake.

I hope you are aware of how fortunate you must be, as that you are the
first to report this error. I imagine that this warrants a special treat.

--
Derek Parnell
Melbourne, Australia
28/04/2005 2:15:06 AM

Unfortunately, I was needed elsewhere and had to run,
so I posted what information I had time to,
with the intention of adding details later,
if I could manage to find anything useful to report.

Thanks for your obvious patience in this matter,
and for not resorting to sarcasm in the interim.

I'll get back to you on it if I can manage to find any
details beyond the error message that I already mentioned.

TZ

Apr 28 2005
Derek Parnell <derek psych.ward> writes:
 On Wed, 27 Apr 2005 10:53:40 -0500, TechnoZeus wrote:
Tried it.
All I got was...
Error: Access Violation

On Thu, 28 Apr 2005 02:08:52 -0500, TechnoZeus wrote:
Unfortunately, I was needed elsewhere and had to run,

It is a pleasure to be needed, no?

so I posted what information I had time to,
with the intention of adding details later,
if I could manage to find anything useful to report.

eg. command line, environment, source code, ... perhaps?

Thanks for your obvious patience in this matter,
and for not resorting to sarcasm in the interim.

You're welcome.

I'll get back to you on it if I can manage to find any
details beyond the error message that I already mentioned.

I shall wait.

--
Derek
Melbourne, Australia
28/04/2005 5:50:24 PM

Apr 28 2005
"TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:oylh3sk27z3m$.1qck73z0ezx99$.dlg 40tude.net...
On Wed, 27 Apr 2005 10:53:40 -0500, TechnoZeus wrote:
Tried it.
All I got was...
Error: Access Violation

On Thu, 28 Apr 2005 02:08:52 -0500, TechnoZeus wrote:
Unfortunately, I was needed elsewhere and had to run,

It is a pleasure to be needed, no?

so I posted what information I had time to,
with the intention of adding details later,
if I could manage to find anything useful to report.

eg. command line, environment, source code, ... perhaps?

Thanks for your obvious patience in this matter,
and for not resorting to sarcasm in the interim.

You're welcome.

I'll get back to you on it if I can manage to find any
details beyond the error message that I already mentioned.

I shall wait.

--
Derek
Melbourne, Australia
28/04/2005 5:50:24 PM

No, I've never really liked being needed.
Wanted would be nice, but needed seems to be persistant.  Sorry, but you asked.
hehe.

Okay, here goes...

F:\dmd\bin>build ..\practice\test0\test
Error: Access Violation
----

F:\dmd\bin>set
TMP=C:\WINDOWS\TEMP
TEMP=C:\WINDOWS\TEMP
PROMPT=$p$g
winbootdir=C:\WINDOWS
COMSPEC=C:\WINDOWS\COMMAND.COM
LIB=c:\masm32\lib;c:\hla\hlalib;
INCLUDE=c:\hla\include;c:\masm32\include;
HLAINC=c:\hla\include
HLALIB=c:\hla\hlalib\hlalib.lib
HOME=C:\Swarm-2.1.1
SWARMDIR=C:\Swarm-2.1.1
PATH=F:\MIKTEX\MIKTEX\BIN;C:\WINDOWS;C:\WINDOWS\COMMAND;C:\WINDOWS\SYSTEM;C:\HLA;C:\MASM32\BIN;C:\MASM32
windir=C:\WINDOWS
SNDSCAPE=C:\WINDOWS
BLASTER=A220 I7 D1 T2
CMDLINE=build ..\practice\test0\test

[f:\dmd\practice\test0\test.d]
import module0;
void main()
{
if (a) writef("true");
if (!a) writef("false");
}

[f:\dmd\practice\test0\module0.d]
bit a = true;

_____

Not the same as what I was testing before, but is simple and causes the same
error.

TZ

Apr 29 2005
Derek Parnell <derek psych.ward> writes:
On Fri, 29 Apr 2005 03:02:16 -0500, TechnoZeus wrote:

F:\dmd\bin>build ..\practice\test0\test
Error: Access Violation

And here is what I get with the same source files ...

-------------------------------------------
F:\dmd\bin>build ..\practice\test0\test
F:\dmd\practice\test0\module0+F:\dmd\practice\t
est0\test,F:\dmd\practice\test0\test.exe,,user32+kernel32,..\practice\test0\test
.def/noi;
-------------------------------------------

So I'm guessing you have a different set up to me. I'm using a stock
standard DigitalMars edition. Have you done any mods to the phobos library?

Can you run you're command line again but with the  -V  switch. This gives
a verbose output that might help us diagnose the problem.

--
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
30/04/2005 12:20:02 PM

Apr 29 2005
"TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:rp54g5m3vciz$.iahswwvkjvos.dlg 40tude.net... On Fri, 29 Apr 2005 03:02:16 -0500, TechnoZeus wrote: F:\dmd\bin>build ..\practice\test0\test Error: Access Violation And here is what I get with the same source files ... ------------------------------------------- F:\dmd\bin>build ..\practice\test0\test f:\dmd\bin\..\..\dm\bin\link.exe F:\dmd\practice\test0\module0+F:\dmd\practice\t est0\test,F:\dmd\practice\test0\test.exe,,user32+kernel32,..\practice\test0\test .def/noi; ------------------------------------------- So I'm guessing you have a different set up to me. I'm using a stock standard DigitalMars edition. Have you done any mods to the phobos library? Can you run you're command line again but with the -V switch. This gives a verbose output that might help us diagnose the problem. -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build 30/04/2005 12:20:02 PM No modifications to the Phobos library. (None that I didn't change back, that is.) Tried the -V switch, and what I got looked to me like it was an indication that build was having trouble reading my sc.ini file... so here is what my si.ini file has in it, in case that helps... [Version] version=7.51 Build 020 [Environment] LIB="% P%\..\lib;\dm\lib" DFLAGS="-I% P%\..\src\phobos;% P%\..\src\dig;% P%\..\practice;.\" LINKCMD=% P%\..\..\dm\bin\link.exe and here is a copy of what I got with the -V switch... F:\dmd\bin>build ..\practice\test0\test -V *** build v2.03 (build 746)*** Current Dir 'F:\dmd\bin\' Compiler installed in Configuration File installed in Active Version: 'X86' Active Version: 'Win32' Active Version: 'LittleEndian' Active Version: 'Windows' Active Version: 'build' Active Version: 'D_InlineAsm' Active Version: 'DigitalMars' Reading from config: sc.ini Line 1: [Version] Line 2: version=7.51 Build 020 Line 3: Line 4: [Environment] Error: Access Violation Hope that helps. TZ  Apr 29 2005 Derek Parnell <derek psych.ward> writes: On Fri, 29 Apr 2005 23:36:28 -0500, TechnoZeus wrote: "Derek Parnell" <derek psych.ward> wrote in message news:rp54g5m3vciz$.iahswwvkjvos.dlg 40tude.net...
On Fri, 29 Apr 2005 03:02:16 -0500, TechnoZeus wrote:

F:\dmd\bin>build ..\practice\test0\test
Error: Access Violation

And here is what I get with the same source files ...

-------------------------------------------
F:\dmd\bin>build ..\practice\test0\test
F:\dmd\practice\test0\module0+F:\dmd\practice\t
est0\test,F:\dmd\practice\test0\test.exe,,user32+kernel32,..\practice\test0\test
.def/noi;
-------------------------------------------

So I'm guessing you have a different set up to me. I'm using a stock
standard DigitalMars edition. Have you done any mods to the phobos library?

Can you run you're command line again but with the  -V  switch. This gives
a verbose output that might help us diagnose the problem.

--
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
30/04/2005 12:20:02 PM

No modifications to the Phobos library.  (None that I didn't change back, that
is.)

Tried the -V switch, and what I got looked to me like it was
an indication that build was having trouble reading my sc.ini file...
so here is what my si.ini file has in it, in case that helps...
[Version]
version=7.51 Build 020

[Environment]
LIB="% P%\..\lib;\dm\lib"
DFLAGS="-I% P%\..\src\phobos;% P%\..\src\dig;% P%\..\practice;.\"

and here is a copy of what I got with the -V switch...

F:\dmd\bin>build ..\practice\test0\test -V
*** build v2.03 (build 746)***
Current Dir 'F:\dmd\bin\'
Compiler installed in
Configuration File installed in
Active Version: 'X86'
Active Version: 'Win32'
Active Version: 'LittleEndian'
Active Version: 'Windows'
Active Version: 'build'
Active Version: 'D_InlineAsm'
Active Version: 'DigitalMars'
Line 1: [Version]
Line 2: version=7.51 Build 020
Line 3:
Line 4: [Environment]
Error: Access Violation

Now we're cooking...can you change the sc.ini LIB line to ...

LIB="% P%\..\lib";\dm\lib

and try it again. This is how it is distributed by DigialMars. I believe
the syntax is supposed to be 'LIB=' followed by one or more paths. A path
is terminated by either a space, a semi-colon, or end of line. Each path
may be enclosed in quotes if it contains spaces.

--
Derek Parnell
Melbourne, Australia
30/April/2005 3:07:04 PM

Apr 29 2005
"TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:1erlmt7ty6948.isce4jbt3htd$.dlg 40tude.net... On Fri, 29 Apr 2005 23:36:28 -0500, TechnoZeus wrote: "Derek Parnell" <derek psych.ward> wrote in message news:rp54g5m3vciz$.iahswwvkjvos.dlg 40tude.net...
On Fri, 29 Apr 2005 03:02:16 -0500, TechnoZeus wrote:

F:\dmd\bin>build ..\practice\test0\test
Error: Access Violation

And here is what I get with the same source files ...

-------------------------------------------
F:\dmd\bin>build ..\practice\test0\test
F:\dmd\practice\test0\module0+F:\dmd\practice\t
est0\test,F:\dmd\practice\test0\test.exe,,user32+kernel32,..\practice\test0\test
.def/noi;
-------------------------------------------

So I'm guessing you have a different set up to me. I'm using a stock
standard DigitalMars edition. Have you done any mods to the phobos library?

Can you run you're command line again but with the  -V  switch. This gives
a verbose output that might help us diagnose the problem.

--
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
30/04/2005 12:20:02 PM

No modifications to the Phobos library.  (None that I didn't change back, that
is.)

Tried the -V switch, and what I got looked to me like it was
an indication that build was having trouble reading my sc.ini file...
so here is what my si.ini file has in it, in case that helps...
[Version]
version=7.51 Build 020

[Environment]
LIB="% P%\..\lib;\dm\lib"
DFLAGS="-I% P%\..\src\phobos;% P%\..\src\dig;% P%\..\practice;.\"

and here is a copy of what I got with the -V switch...

F:\dmd\bin>build ..\practice\test0\test -V
*** build v2.03 (build 746)***
Current Dir 'F:\dmd\bin\'
Compiler installed in
Configuration File installed in
Active Version: 'X86'
Active Version: 'Win32'
Active Version: 'LittleEndian'
Active Version: 'Windows'
Active Version: 'build'
Active Version: 'D_InlineAsm'
Active Version: 'DigitalMars'
Line 1: [Version]
Line 2: version=7.51 Build 020
Line 3:
Line 4: [Environment]
Error: Access Violation

Now we're cooking...can you change the sc.ini LIB line to ...

LIB="% P%\..\lib";\dm\lib

and try it again. This is how it is distributed by DigialMars. I believe
the syntax is supposed to be 'LIB=' followed by one or more paths. A path
is terminated by either a space, a semi-colon, or end of line. Each path
may be enclosed in quotes if it contains spaces.

--
Derek Parnell
Melbourne, Australia
30/April/2005 3:07:04 PM

Oh, that's not the problem.
I wasn't sure what format that line was supposed to have, but
when I tried it before, I had quotes around only the first path, as you have it
there...
and got the same error.  Since then, I did some experimenting with various
formats,
some of which stopped the compiler from working right at all.
The configuration I showed you just happened to be the one that had worked best
so far.

Anyway, just to be certain, I'll run another test, and paste the results here...

[Version]
version=7.51 Build 020

[Environment]
LIB="% P%\..\lib";"\dm\lib"
DFLAGS="-I% P%\..\src\phobos";"% P%\..\src\dig";"% P%\..\practice";".\"

F:\dmd\bin>build ..\practice\test0\test -V
*** build v2.03 (build 746)***
Current Dir 'F:\dmd\bin\'
Compiler installed in
Configuration File installed in
Active Version: 'X86'
Active Version: 'Win32'
Active Version: 'LittleEndian'
Active Version: 'Windows'
Active Version: 'build'
Active Version: 'D_InlineAsm'
Active Version: 'DigitalMars'
Line 1: [Version]
Line 2: version=7.51 Build 020
Line 3:
Line 4: [Environment]
Error: Access Violation

Hmmm.....
Still says Access Violation right after Line 4: [Environment]

I wonder if there's something in my environment that it can't handle...

F:\dmd\bin>set
TMP=C:\WINDOWS\TEMP
TEMP=C:\WINDOWS\TEMP
PROMPT=$p$g
winbootdir=C:\WINDOWS
COMSPEC=C:\WINDOWS\COMMAND.COM
LIB=c:\masm32\lib;c:\hla\hlalib;
INCLUDE=c:\hla\include;c:\masm32\include;
HLAINC=c:\hla\include
HLALIB=c:\hla\hlalib\hlalib.lib
HOME=C:\Swarm-2.1.1
SWARMDIR=C:\Swarm-2.1.1
PATH=F:\MIKTEX\MIKTEX\BIN;C:\WINDOWS;C:\WINDOWS\COMMAND;C:\WINDOWS\SYSTEM;F:\GTK\BIN
windir=C:\WINDOWS
SNDSCAPE=C:\WINDOWS
BLASTER=A220 I7 D1 T2
CMDLINE=build ..\practice\test0\test -V

Nothing in there looks to me like it should cause a problem.
I do see something in my path though that I'm going to remove as soon as I'm
ready to go offline and reboot.  That MIKTEX entry doesn't need to be there.  I

Sorry I can't be any more hlep.  Would if I could.

TZ

Apr 30 2005
Derek Parnell <derek psych.ward> writes:
On Sat, 30 Apr 2005 14:56:05 -0500, TechnoZeus wrote:

[snip]

Anyway, just to be certain, I'll run another test, and paste the results
here...

[Version]
version=7.51 Build 020

[Environment]
LIB="% P%\..\lib";"\dm\lib"
DFLAGS="-I% P%\..\src\phobos";"% P%\..\src\dig";"% P%\..\practice";".\"

F:\dmd\bin>build ..\practice\test0\test -V
*** build v2.03 (build 746)***
Current Dir 'F:\dmd\bin\'
Compiler installed in
Configuration File installed in
Active Version: 'X86'
Active Version: 'Win32'
Active Version: 'LittleEndian'
Active Version: 'Windows'
Active Version: 'build'
Active Version: 'D_InlineAsm'
Active Version: 'DigitalMars'
Line 1: [Version]
Line 2: version=7.51 Build 020
Line 3:
Line 4: [Environment]
Error: Access Violation

Hmmm.....
Still says Access Violation right after Line 4: [Environment]

[snip]
PATH=F:\MIKTEX\MIKTEX\BIN;C:\WINDOWS;C:\WINDOWS\COMMAND;C:\WINDOWS\SYSTEM;F:\GTK\BIN

[snip]

I've finally been able to reproduce the problem you have been reporting.

It is a bug in one of the support modules that Build uses, so I can fix
that. It was triggered because there is no entry in your PATH environment
symbol for "f:\dmd\bin" and thus it assumed that the path to the
configuration file was "".

Just to confirm that this is the problem can I please ask another favor.
Can you run the Build command line again but with the following switches...

build ..\practice\test0\test -CFPATHf:\dmd\bin -DCPATHf:\dmd\bin -V

In the mean time, I'll correct my mistake.

--
Derek Parnell
Melbourne, Australia
1/05/2005 8:55:05 AM

Apr 30 2005
"TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Ah, yes.  Short on environment space here, so I didn't add dmd\bin to my path
variable.
I usually run it from a Windows context menu, by right clicking on the file
that I want to compile.
If I use build in the long run, I will probably try to find a way to set it up
to run from a context menu also.

Here's the output from what you just asked me to try...

F:\dmd\bin>build ..\practice\test0\test -CFPATHf:\dmd\bin -DCPATHf:\dmd\bin -V
F:\dmd\practice\test0\module0+F:\dmd\practice\test0\test,F:\dmd\practice\test0\test.exe,,user32+kernel32,..\practice\test0\test.def/noi;

OPTLINK (R) for Win32  Release 7.50B1

F:\dmd\practice\test0\module0.obj
--- errorlevel 1
*** build v2.03 (build 746)***
CFPATH was  now f:\dmd\bin
DCPATH was  now f:\dmd\bin
Current Dir 'F:\dmd\bin\'
Compiler installed in f:\dmd\bin\
Configuration File installed in f:\dmd\bin\
Active Version: 'X86'
Active Version: 'Win32'
Active Version: 'LittleEndian'
Active Version: 'Windows'
Active Version: 'build'
Active Version: 'D_InlineAsm'
Active Version: 'DigitalMars'
Line 1: [Version]
Line 2: version=7.51 Build 020
Line 3:
Line 4: [Environment]
Line 5: LIB="f:\dmd\bin\..\lib";"\dm\lib"
use LIB="f:\dmd\lib\";"\dm\lib\"
Line 6: DFLAGS="-If:\dmd\bin\..\src\phobos";"f:\dmd\bin\..\src\dig";"f:\dmd\bin\..\practice";".\"
added root from config file f:\dmd\src\phobos\
file->module F:\dmd\practice\test0\test.d => .dmd.practice.test0.test
Time not recorded for F:\dmd\practice\test0\test.d
Time not recorded for F:\dmd\practice\test0\test.obj
Scanning F:\dmd\practice\test0\test.d
module->file module0 => F:\dmd\practice\test0\module0.d
file->module F:\dmd\practice\test0\module0.d => .dmd.practice.test0.module0
Time not recorded for F:\dmd\practice\test0\module0.d
Time not recorded for F:\dmd\practice\test0\module0.obj
Scanning F:\dmd\practice\test0\module0.d
source file[0] F:\dmd\practice\test0\module0.d
source file[1] F:\dmd\practice\test0\test.d

Building target '..\practice\test0\test.exe'
Time not recorded for F:\dmd\practice\test0\test.exe (target)
Time not recorded (most recent)
Compiling with ..........
"-op"
"-If:\dmd\bin\..\src\phobos"
"F:\dmd\practice\test0\module0.obj"
"F:\dmd\practice\test0\test.obj"
"..\practice\test0\test.def"
"-ofF:\dmd\practice\test0\test.exe"

Running 'f:\dmd\bin\dmd.exe  ..\practice\test0\test.rsp'
Successful

build args: ...............
[ 0]: -CFPATHf:\dmd\bin
[ 1]: -DCPATHf:\dmd\bin
[ 2]: -V

compiler args: ................
[ 0]: -op
[ 1]: -If:\dmd\bin\..\src\phobos

command line files: ...............
[ 0]: ..\practice\test0\test.d

declared source files: ...............
[ 0]: F:\dmd\practice\test0\module0.d
[ 1]: F:\dmd\practice\test0\test.d

import roots: .................
[ 0]: f:\dmd\src\phobos\
[ 1]: F:\dmd\practice\test0\

ignored packages: .................
[ 0]: phobos

"Derek Parnell" <derek psych.ward> wrote in message
news:161fcfhnfdou0$.66yz4jkpr7qe$.dlg 40tude.net...
On Sat, 30 Apr 2005 14:56:05 -0500, TechnoZeus wrote:

[snip]

Anyway, just to be certain, I'll run another test, and paste the results
here...

[Version]
version=7.51 Build 020

[Environment]
LIB="% P%\..\lib";"\dm\lib"
DFLAGS="-I% P%\..\src\phobos";"% P%\..\src\dig";"% P%\..\practice";".\"

F:\dmd\bin>build ..\practice\test0\test -V
*** build v2.03 (build 746)***
Current Dir 'F:\dmd\bin\'
Compiler installed in
Configuration File installed in
Active Version: 'X86'
Active Version: 'Win32'
Active Version: 'LittleEndian'
Active Version: 'Windows'
Active Version: 'build'
Active Version: 'D_InlineAsm'
Active Version: 'DigitalMars'
Line 1: [Version]
Line 2: version=7.51 Build 020
Line 3:
Line 4: [Environment]
Error: Access Violation

Hmmm.....
Still says Access Violation right after Line 4: [Environment]

[snip]
PATH=F:\MIKTEX\MIKTEX\BIN;C:\WINDOWS;C:\WINDOWS\COMMAND;C:\WINDOWS\SYSTEM;F:\GTK\BIN

[snip]

I've finally been able to reproduce the problem you have been reporting.

It is a bug in one of the support modules that Build uses, so I can fix
that. It was triggered because there is no entry in your PATH environment
symbol for "f:\dmd\bin" and thus it assumed that the path to the
configuration file was "".

Just to confirm that this is the problem can I please ask another favor.
Can you run the Build command line again but with the following switches...

build ..\practice\test0\test -CFPATHf:\dmd\bin -DCPATHf:\dmd\bin -V

In the mean time, I'll correct my mistake.

--
Derek Parnell
Melbourne, Australia
1/05/2005 8:55:05 AM

When I got done with that, I tried to run the resulting MODULE0.exe

first, from the f:\dmd\bin folder, where I was given an error message stating
that it was not a valid WIN32 application.

Then from an MS-DOS prompt window, where I got a message stating...
"This program has performed an illegal operation and will be terminated.
Quit all programs, and then restart your computer.
If the program consistantly encounters problems, click the Start button,
then select Help, Troubleshooting, and 'If you have trouble running
MS-DOS programs'.

I don't know if this information is of any use to you, but... there it is.

TZ

May 01 2005
Derek Parnell <derek psych.ward> writes:
[snip]

Time not recorded for F:\dmd\practice\test0\test.d

You wouldn't happen to be running an old version of Windows, by any chance?
Maybe Win98, or ME, or 95?

It has been reported that the GetFileTime routine doesn't work for these
old Windows versions. If that is the case, then Build does has a bug in
that it thinks that the object file exists when it really doesn't, so it
doesn't try to re-compile the corresponding source. Thus the linker fails
to find the object file.

I guess I had better support ancient Windows versions after all, dammit!
;-)

--
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
2/May/2005 12:24:24 AM

May 01 2005
"TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:1oe708tzyana1.wc45tzpby5wt$.dlg 40tude.net... [snip] Time not recorded for F:\dmd\practice\test0\test.d You wouldn't happen to be running an old version of Windows, by any chance? Maybe Win98, or ME, or 95? It has been reported that the GetFileTime routine doesn't work for these old Windows versions. If that is the case, then Build does has a bug in that it thinks that the object file exists when it really doesn't, so it doesn't try to re-compile the corresponding source. Thus the linker fails to find the object file. I guess I had better support ancient Windows versions after all, dammit! ;-) -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build 2/May/2005 12:24:24 AM Yep. Running Windows 98 on this system. --- System Information: OS: Windows 98 A (4.10, Build 2222 English) BIOS: Award Modular v4.51PG Processor: Intel Pentium III, ~450MHz Memory: 62MB RAM Page File: 1985MB DirectX Version: DirectX 9.0c DirectDraw, Direct3D, DirectSound, DirectMusic, DDraw, D3D7, D3D8, D3D9, Music: All tests were successful. Display 1 Video card: ATI Rage 128 GL SD AGP (English) Current Mode: 1024 x 768 (32 bit)(default refresh rate) Monitor 1: HP D5258A Pavilion M50 Monitor Display Memory: 16.0 MB Display 1 Driver Name: ATI2DRAA.DRV Version 4.12.0001.6269 (English) DDI Version: 7 DDraw Status, D3D Status, AGP Status: Enabled Display 2 Video card: Cirrus Logic 5446 PCI CL-GD5446 Rev 0 Display 2 Monitor: AcerView 11D Sound Device: Creative SBPCI Direct Sound Driver Version 4.05.00.1139 (ES1371.VXD) Sound card name: Creative SB Live! Wave Device Sound driver: ctmm16.drv Disk & DVD/CD-ROM Drives: 13.0 GB FAT32 IDE, 114.4 GB FAT32 WD1200LB-22EDA0, CD-Writer, CD-ROM --- TZ  May 04 2005 Derek Parnell <derek psych.ward> writes: On Wed, 4 May 2005 02:01:14 -0500, TechnoZeus wrote: Time not recorded for F:\dmd\practice\test0\test.d You wouldn't happen to be running an old version of Windows, by any chance? Maybe Win98, or ME, or 95? Yep. Running Windows 98 on this system. Thought so. I have updated Build to cater for old Windows versions now. I was assuming that filenames were stored in Unicode form and didn't allow simple ASCII ones. The Windows NT family stores the filenames as Unicode but other versions of Windows just uses ASCII. Also, I was using a technique to get a human readable date-time that only worked with Windows NT/2000/XP, but I've got the (slower) more generic one in now for older Windows. The problem is though is that I don't have access to an old Windows box anymore to test this on. So can I ask you to try once more, and with the -V switch, to see if I've still got some more fixing to do. You might want to hold of downloading Build for a couple of hours as I'm just about to upload v2.06 (fixes an obscure bug with the -Rn switch on Windows environments). -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build/ v2.05 released 02/May/2005 http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage 4/05/2005 5:36:41 PM  May 04 2005 "TechnoZeus" <TechnoZeus PeoplePC.com> writes: "Derek Parnell" <derek psych.ward> wrote in message news:1m0hdojs1of36$.2gl8x5iie4mz$.dlg 40tude.net... On Wed, 4 May 2005 02:01:14 -0500, TechnoZeus wrote: Time not recorded for F:\dmd\practice\test0\test.d You wouldn't happen to be running an old version of Windows, by any chance? Maybe Win98, or ME, or 95? Yep. Running Windows 98 on this system. Thought so. I have updated Build to cater for old Windows versions now. I was assuming that filenames were stored in Unicode form and didn't allow simple ASCII ones. The Windows NT family stores the filenames as Unicode but other versions of Windows just uses ASCII. Also, I was using a technique to get a human readable date-time that only worked with Windows NT/2000/XP, but I've got the (slower) more generic one in now for older Windows. The problem is though is that I don't have access to an old Windows box anymore to test this on. So can I ask you to try once more, and with the -V switch, to see if I've still got some more fixing to do. You might want to hold of downloading Build for a couple of hours as I'm just about to upload v2.06 (fixes an obscure bug with the -Rn switch on Windows environments). -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build/ v2.05 released 02/May/2005 http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage 4/05/2005 5:36:41 PM Okay. Can't get to it right now, but when I have time, I will download the new version and run a few tests. I wonder if parts of D are making that same assumption. That might explain some of the long-filename related problems. TZ  May 04 2005 "TechnoZeus" <TechnoZeus PeoplePC.com> writes: "Derek Parnell" <derek psych.ward> wrote in message news:1m0hdojs1of36$.2gl8x5iie4mz$.dlg 40tude.net... On Wed, 4 May 2005 02:01:14 -0500, TechnoZeus wrote: *snip* The problem is though is that I don't have access to an old Windows box anymore to test this on. So can I ask you to try once more, and with the -V switch, to see if I've still got some more fixing to do. You might want to hold of downloading Build for a couple of hours as I'm just about to upload v2.06 (fixes an obscure bug with the -Rn switch on Windows environments). -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build/ v2.05 released 02/May/2005 http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage 4/05/2005 5:36:41 PM Was just about to run that test for you, but the dsource.org web site seems to be down. TZ  May 07 2005 Derek Parnell <derek psych.ward> writes: On Sat, 7 May 2005 18:54:23 -0500, TechnoZeus wrote: Was just about to run that test for you, but the dsource.org web site seems to be down. I've made it available at my site until dsource.org is back up. http://www.users.bigpond.com/ddparnell/build_win_2.07.exe (173.0 KB) http://www.users.bigpond.com/ddparnell/build-2.07.src.zip ( 57.4 KB) http://www.users.bigpond.com/ddparnell/build-2.07.doc.zip ( 24.5 KB) -- Derek Parnell Melbourne, Australia 8/05/2005 10:09:52 AM  May 07 2005 "TechnoZeus" <TechnoZeus PeoplePC.com> writes: "Derek Parnell" <derek psych.ward> wrote in message news:16wnjoxkkvjjo$.vmg3oc7dq1wv.dlg 40tude.net...
On Sat, 7 May 2005 18:54:23 -0500, TechnoZeus wrote:

Was just about to run that test for you, but the dsource.org web site seems to
be down.

I've made it available at my site until dsource.org is back up.

http://www.users.bigpond.com/ddparnell/build_win_2.07.exe (173.0 KB)
http://www.users.bigpond.com/ddparnell/build-2.07.src.zip ( 57.4 KB)
http://www.users.bigpond.com/ddparnell/build-2.07.doc.zip ( 24.5 KB)

--
Derek Parnell
Melbourne, Australia
8/05/2005 10:09:52 AM

Thanks.  Here goes...

F:\dmd\bin>build ..\practice\test0\test -CFPATHf:\dmd\bin -DCPATHf:\dmd\bin -V
F:\dmd\practice\test0\module0+F:\dmd\practice\test0\test,F:\dmd\practice\test0\test.exe,,user32+kernel32,..\practice\test0\test.def/noi;

OPTLINK (R) for Win32  Release 7.50B1

F:\dmd\practice\test0\module0.obj
--- errorlevel 1
*** build v2.03 (build 746)***
CFPATH was  now f:\dmd\bin
DCPATH was  now f:\dmd\bin
Current Dir 'F:\dmd\bin\'
Compiler installed in f:\dmd\bin\
Configuration File installed in f:\dmd\bin\
Active Version: 'X86'
Active Version: 'Win32'
Active Version: 'LittleEndian'
Active Version: 'Windows'
Active Version: 'build'
Active Version: 'D_InlineAsm'
Active Version: 'DigitalMars'
Line 1: [Version]
Line 2: version=7.51 Build 020
Line 3:
Line 4: [Environment]
Line 5: LIB="f:\dmd\bin\..\lib";"\dm\lib"
use LIB="f:\dmd\lib\";"\dm\lib\"
Line 6: DFLAGS="-If:\dmd\bin\..\src\phobos";"f:\dmd\bin\..\src\dig";"f:\dmd\bin\..\practice";".\"
added root from config file f:\dmd\src\phobos\
file->module F:\dmd\practice\test0\test.d => .dmd.practice.test0.test
Time not recorded for F:\dmd\practice\test0\test.d
Time not recorded for F:\dmd\practice\test0\test.obj
Scanning F:\dmd\practice\test0\test.d
module->file module0 => F:\dmd\practice\test0\module0.d
file->module F:\dmd\practice\test0\module0.d => .dmd.practice.test0.module0
Time not recorded for F:\dmd\practice\test0\module0.d
Time not recorded for F:\dmd\practice\test0\module0.obj
Scanning F:\dmd\practice\test0\module0.d
source file[0] F:\dmd\practice\test0\module0.d
source file[1] F:\dmd\practice\test0\test.d

Building target '..\practice\test0\test.exe'
Time not recorded for F:\dmd\practice\test0\test.exe (target)
Time not recorded (most recent)
Compiling with ..........
"-op"
"-If:\dmd\bin\..\src\phobos"
"F:\dmd\practice\test0\module0.obj"
"F:\dmd\practice\test0\test.obj"
"..\practice\test0\test.def"
"-ofF:\dmd\practice\test0\test.exe"

Running 'f:\dmd\bin\dmd.exe  ..\practice\test0\test.rsp'
Successful

build args: ...............
[ 0]: -CFPATHf:\dmd\bin
[ 1]: -DCPATHf:\dmd\bin
[ 2]: -V

compiler args: ................
[ 0]: -op
[ 1]: -If:\dmd\bin\..\src\phobos

command line files: ...............
[ 0]: ..\practice\test0\test.d

declared source files: ...............
[ 0]: F:\dmd\practice\test0\module0.d
[ 1]: F:\dmd\practice\test0\test.d

import roots: .................
[ 0]: f:\dmd\src\phobos\
[ 1]: F:\dmd\practice\test0\

ignored packages: .................
[ 0]: phobos

-------------------------------

Does that tell you anything useful at all?

If you would like me to try different source code or anything like that, let me
know what you would like me ot try, and I'll see if I can run another test or
two for you, since you don't have a Win98 machine to test on.

TZ

May 07 2005
Derek Parnell <derek psych.ward> writes:
On Sat, 7 May 2005 20:50:07 -0500, TechnoZeus wrote:

"Derek Parnell" <derek psych.ward> wrote in message
news:16wnjoxkkvjjo$.vmg3oc7dq1wv.dlg 40tude.net... On Sat, 7 May 2005 18:54:23 -0500, TechnoZeus wrote: Was just about to run that test for you, but the dsource.org web site seems to be down. I've made it available at my site until dsource.org is back up. http://www.users.bigpond.com/ddparnell/build_win_2.07.exe (173.0 KB) http://www.users.bigpond.com/ddparnell/build-2.07.src.zip ( 57.4 KB) http://www.users.bigpond.com/ddparnell/build-2.07.doc.zip ( 24.5 KB) -- Derek Parnell Melbourne, Australia 8/05/2005 10:09:52 AM Thanks. Here goes... F:\dmd\bin>build ..\practice\test0\test -CFPATHf:\dmd\bin -DCPATHf:\dmd\bin -V F:\DMD\BIN\..\..\dm\bin\link.exe F:\dmd\practice\test0\module0+F:\dmd\practice\test0\test,F:\dmd\practice\test0\test.exe,,user32+kernel32,..\practice\test0\test.def/noi; OPTLINK (R) for Win32 Release 7.50B1 Copyright (C) Digital Mars 1989 - 2001 All Rights Reserved F:\dmd\practice\test0\module0.obj Error 2: File Not Found F:\dmd\practice\test0\module0.obj --- errorlevel 1 *** build v2.03 (build 746)*** [snip] Does that tell you anything useful at all? If you would like me to try different source code or anything like that, let me know what you would like me ot try, and I'll see if I can run another test or two for you, since you don't have a Win98 machine to test on. Ummm, the idea was for you to try the current version of Build (v2.07) and not the older v2.03. I believe I fixed the Windows 98 issue in v2.06. While dsource.org is down, you can use ... http://www.users.bigpond.com/ddparnell/build/download.html -- Derek Parnell Melbourne, Australia 8/05/2005 5:57:02 PM  May 08 2005 "TechnoZeus" <TechnoZeus PeoplePC.com> writes: "Derek Parnell" <derek psych.ward> wrote in message news:yyalrjz7ko8v$.vaizgxylmb1q.dlg 40tude.net...
On Sat, 7 May 2005 20:50:07 -0500, TechnoZeus wrote:

"Derek Parnell" <derek psych.ward> wrote in message
news:16wnjoxkkvjjo$.vmg3oc7dq1wv.dlg 40tude.net... On Sat, 7 May 2005 18:54:23 -0500, TechnoZeus wrote: Was just about to run that test for you, but the dsource.org web site seems to be down. I've made it available at my site until dsource.org is back up. http://www.users.bigpond.com/ddparnell/build_win_2.07.exe (173.0 KB) http://www.users.bigpond.com/ddparnell/build-2.07.src.zip ( 57.4 KB) http://www.users.bigpond.com/ddparnell/build-2.07.doc.zip ( 24.5 KB) -- Derek Parnell Melbourne, Australia 8/05/2005 10:09:52 AM Thanks. Here goes... F:\dmd\bin>build ..\practice\test0\test -CFPATHf:\dmd\bin -DCPATHf:\dmd\bin -V F:\DMD\BIN\..\..\dm\bin\link.exe F:\dmd\practice\test0\module0+F:\dmd\practice\test0\test,F:\dmd\practice\test0\test.exe,,user32+kernel32,..\practice\test0\test.def/noi; OPTLINK (R) for Win32 Release 7.50B1 Copyright (C) Digital Mars 1989 - 2001 All Rights Reserved F:\dmd\practice\test0\module0.obj Error 2: File Not Found F:\dmd\practice\test0\module0.obj --- errorlevel 1 *** build v2.03 (build 746)*** [snip] Does that tell you anything useful at all? If you would like me to try different source code or anything like that, let me know what you would like me ot try, and I'll see if I can run another test or two for you, since you don't have a Win98 machine to test on. Ummm, the idea was for you to try the current version of Build (v2.07) and not the older v2.03. I believe I fixed the Windows 98 issue in v2.06. While dsource.org is down, you can use ... http://www.users.bigpond.com/ddparnell/build/download.html -- Derek Parnell Melbourne, Australia 8/05/2005 5:57:02 PM Hmmm. I thought I did use the newer version. Not sure what happened there. I'll give it another try, and actually "look at the output" thistime before sending it. ---- Odd... I checked it, and the version that I had in place was the latest one. Must have mixed up the output files or something. Anyway, I deleted all the old test output and re-downloaded the latest version, just in case. build ..\practice\test0\test -CFPATHf:\dmd\bin -DCPATHf:\dmd\bin -V F:\dmd\practice\test0\test.d(5): undefined identifier writef F:\dmd\practice\test0\test.d(5): function expected before (), not 'int' F:\dmd\practice\test0\test.d(6): undefined identifier writef F:\dmd\practice\test0\test.d(6): function expected before (), not 'int' *** build v2.07 (build 912)*** CFPATH was now f:\dmd\bin DCPATH was F:\dmd\bin\ now f:\dmd\bin Current Dir 'F:\dmd\bin\' dmd.exe not found in PATH symbol, so assuming current directory Compiler installed in f:\dmd\bin\ Configuration File installed in f:\dmd\bin\ Active Version: 'X86' Active Version: 'Win32' Active Version: 'LittleEndian' Active Version: 'Windows' Active Version: 'build' Active Version: 'D_InlineAsm' Active Version: 'DigitalMars' Reading from config: f:\dmd\bin\sc.ini Line 1: [Version] Line 2: version=7.51 Build 020 Line 3: Line 4: [Environment] Line 5: LIB="% P%\..\lib";"\dm\lib" use LIB="f:\dmd\lib\";"\dm\lib\" Line 6: DFLAGS=-I"% P%\..\src\phobos\";"% P%\..\src\dig\";"% P%\..\practice\";".\";"% P%\..\src\phobos\std\";"% P%\..\src\phobos\std\c\windows\" added root from config file f:\dmd\src\phobos\ added root from config file f:\dmd\src\dig\ added root from config file f:\dmd\practice\ added root from config file F:\dmd\bin\ added root from config file f:\dmd\src\phobos\std\ added root from config file f:\dmd\src\phobos\std\c\windows\ Line 7: LINKCMD=% P%\..\..\dm\bin\link.exe librarian path f:\dm\bin\ source file[0] F:\dmd\practice\test0\module0.d Newer time: from not recorded to 2005/04/24 18:00:32 source file[1] F:\dmd\practice\test0\test.d Newer time: from 2005/04/24 18:00:32 to 2005/04/24 18:01:48 Building target '..\practice\test0\test.exe' Time not recorded for F:\dmd\practice\test0\test.exe (target) Time 2005/04/24 18:01:48 (most recent) F:\dmd\practice\test0\module0.d newer than its object file F:\dmd\practice\test0\test.d newer than its object file Compiling with .......... -op -If:\dmd\bin\..\src\phobos\ -If:\dmd\bin\..\src\dig\ -If:\dmd\bin\..\practice\ -I.\ -If:\dmd\bin\..\src\phobos\std\ -If:\dmd\bin\..\src\phobos\std\c\windows\ F:\dmd\practice\test0\module0.d F:\dmd\practice\test0\test.d ..\practice\test0\test.def -ofF:\dmd\practice\test0\test.exe Running 'f:\dmd\bin\dmd.exe ..\practice\test0\test.rsp' Successful build args: ............... [ 0]: -CFPATHf:\dmd\bin [ 1]: -DCPATHf:\dmd\bin [ 2]: -V compiler args: ................ [ 0]: -op [ 1]: -If:\dmd\bin\..\src\phobos\ [ 2]: -If:\dmd\bin\..\src\dig\ [ 3]: -If:\dmd\bin\..\practice\ [ 4]: -I.\ [ 5]: -If:\dmd\bin\..\src\phobos\std\ [ 6]: -If:\dmd\bin\..\src\phobos\std\c\windows\ command line files: ............... [ 0]: ..\practice\test0\test.d declared source files: ............... [ 0]: F:\dmd\practice\test0\module0.d [ 1]: F:\dmd\practice\test0\test.d import roots: ................. [ 0]: f:\dmd\src\phobos\ [ 1]: f:\dmd\src\dig\ [ 2]: f:\dmd\practice\ [ 3]: F:\dmd\bin\ [ 4]: f:\dmd\src\phobos\std\ [ 5]: f:\dmd\src\phobos\std\c\windows\ [ 6]: F:\dmd\practice\test0\ ignored packages: ................. [ 0]: phobos -------- and here's what I got without the -V switch: ------- F:\dmd\practice\test0\test.d(5): undefined identifier writef F:\dmd\practice\test0\test.d(5): function expected before (), not 'int' F:\dmd\practice\test0\test.d(6): undefined identifier writef F:\dmd\practice\test0\test.d(6): function expected before (), not 'int' which as far as I know is exactly what I should be getting, since I don't have an import for the writef function (although I still think D should import that one without having to be "told to" but that's another subject.) Anyway, I added the std.stdio import to test it further and compiled it again, and it works fine now. Congratulations. :) Unfortunately for me though, I'm still no closer to having an answer to my original question of how to set up D to look for import modules in the same path as the source file that imports them... F:\dmd\bin>dmd ..\practice\test0\test.d Error: Error reading file 'module0.d' F:\dmd\bin>build ..\practice\test0\test.d Error: Error reading file 'module0.d' TZ  May 08 2005 Derek Parnell <derek psych.ward> writes: On Sun, 8 May 2005 15:21:16 -0500, TechnoZeus wrote: [snip] Compiling with .......... -op -If:\dmd\bin\..\src\phobos\ -If:\dmd\bin\..\src\dig\ -If:\dmd\bin\..\practice\ -I.\ -If:\dmd\bin\..\src\phobos\std\ -If:\dmd\bin\..\src\phobos\std\c\windows\ F:\dmd\practice\test0\module0.d F:\dmd\practice\test0\test.d ..\practice\test0\test.def -ofF:\dmd\practice\test0\test.exe Running 'f:\dmd\bin\dmd.exe ..\practice\test0\test.rsp' Successful [snip] Congratulations. :) Thank you. I'm glad that people with old Windows system can also use this tool now. Unfortunately for me though, I'm still no closer to having an answer to my original question of how to set up D to look for import modules in the same path as the source file that imports them... F:\dmd\bin>dmd ..\practice\test0\test.d Error: Error reading file 'module0.d' F:\dmd\bin>build ..\practice\test0\test.d Error: Error reading file 'module0.d' I just re-read your original question ... "How do you specify an include path relative to your source path in the sc.ini file?" The strict answer to this is you can't. There is no provision for symbolically naming the directory of the current source file in the sc.ini commands. You can only symbolically name the directory of the sc.ini file itself - via the ' P' special name. In Build's use of its own configuration file, I have already added the use of the special name ' D' to refer to the compiler's location, but DMD does not recognize that for sc.ini. So it would seem that in the sc.ini file, you can only specify locations in absolute terms, or relative to the sc.ini file's location, or relative to the current directory. Thus you may have to set your current directory to be the source file's location before compiling it. -- Derek Melbourne, Australia 9/05/2005 9:19:56 AM  May 08 2005 "TechnoZeus" <TechnoZeus PeoplePC.com> writes: "Derek Parnell" <derek psych.ward> wrote in message news:9dh6z3nm56y3$.jee04ewtn8su.dlg 40tude.net...
On Sun, 8 May 2005 15:21:16 -0500, TechnoZeus wrote:

Thank you. I'm glad that people with old Windows system can also use this
tool now.

me too.

"How do you specify an include path relative to your source path in the
sc.ini file?"

The strict answer to this is you can't. There is no provision for
symbolically naming the directory of the current source file in the sc.ini
commands. You can only symbolically name the directory of the sc.ini file
itself - via the ' P' special name. In Build's use of its own configuration
file, I have already added the use of the special name ' D' to refer to the
compiler's location, but DMD does not recognize that for sc.ini.

So it would seem that in the sc.ini file, you can only specify locations in
absolute terms, or relative to the sc.ini file's location, or relative to
the current directory. Thus you may have to set your current directory to
be the source file's location before compiling it.

--
Derek
Melbourne, Australia
9/05/2005 9:19:56 AM

Yes, you would think that would work... but here's what I got testing it that
way...

F:\dmd\bin>cd ..\practice\test0

F:\dmd\Practice\test0>..\..\bin\dmd test
OPTLINK (R) for Win32  Release 7.50B1

test.obj(test)
Error 42: Symbol Undefined _D7module01ab
--- errorlevel 1

and also, I usually compile from a context menu... not a command prompt.
In Windows XP, it would be easy to specify a path relative to the original
source file
in a context menu option, but not in Win98... and I can't even think of a way in
Windows XP of specifying to look for modules in a the same path as the file
that inports them.

This should, in my opinion, happen by default...
because it would allow interdependant modules to be grouped in the same
directory where they
could import each other as needed without any paths having to be specified.
I have seen several cases already of modules written to import a file that is
part of the same package and
as such is stored in the same folder, and almost always the import statement
only specifies the unqualified module name.
...making it necessary to add yet another path to the %path% environment
variable.   Unfortunately, that space is limited.

Parhaps if you set up a way in build to address a path relative to that of the
"current module" ( C maybe?) and suggest that DMD adopt the
same convention, it might just happen... some day.  :)

Also, if a module isn't found elsewhere, perhaps you could have build look
aotumatically for it in the path of the file that tried to import it.
Personally, I think that location should be checked "first" so that the author
of a package can assure that the module in their package will be used...
but it would probably be bad to have build do that unless DMD did also, to
avoid having them compile "differently".  On the other hand...
I see no harm in getting build to succede at getting a program to compile in
it's own way where DMD alone would otherwise have simply failed.

TZ

May 08 2005
Derek Parnell <derek psych.ward> writes:
On Sun, 8 May 2005 22:36:07 -0500, TechnoZeus wrote:

"Derek Parnell" <derek psych.ward> wrote in message
news:9dh6z3nm56y3$.jee04ewtn8su.dlg 40tude.net... [snip] Thus you may have to set your current directory to be the source file's location before compiling it. Yes, you would think that would work... but here's what I got testing it that way... F:\dmd\bin>cd ..\practice\test0 F:\dmd\Practice\test0>..\..\bin\dmd test F:\DMD\BIN\..\..\dm\bin\link.exe test,,,user32+kernel32/noi; OPTLINK (R) for Win32 Release 7.50B1 Copyright (C) Digital Mars 1989 - 2001 All Rights Reserved test.obj(test) Error 42: Symbol Undefined _D7module01ab --- errorlevel 1 In defence of Walter's dmd, by giving the command "dmd test" you are asking two things ... (1) Compile the file 'test.d' - which it did correctly, and (2) Link 'test.obj', and various modules from 'phobos.lib', 'user32.lib', and 'kernel32.lib' in order to form an executable. It attempted to link these together to form the executable but it couldn't succeed because the linker didn't know where to find the module0 module. To emphasis: the compiler knew where to find module0.d, but the linker didn't know where to find module0.obj. I know that your source code "test.d" contains the line "import module0;" (or similar). The DMD compiler uses that line during the *compilation* phase to compile test.d. It did this successfully. The linker does not read source code so if you want a module to be included in the *linking* process, you have to tell the linker were to get it from. And that could theoretically be from either a .obj file or a .lib file. The linker doesn't know where you might have stored it. In fact, the dmd compiler doesn't know either. You have to explicitly tell the linker this info. The way to tell the linker is to place the location on the dmd command line. Either as the source code name, the object file name or a library name. Thus that is why you need to use ... dmd test module0 Simply: The linker needs to know where to find things, and this how you tell it. The above command line is actually a short cut for ... dmd -c test.d dmd -c module0.d dmd test.obj module0.obj -oftest.exe And this is why I created Build. Now all I have to do is ... build test and it works out all the details for me. and also, I usually compile from a context menu... not a command prompt. In Windows XP, it would be easy to specify a path relative to the original source file in a context menu option, but not in Win98... and I can't even think of a way in Windows XP of specifying to look for modules in a the same path as the file that inports them. I suspect you are merging *compiling* and *linking* into one concept. The compiler does find the modules' source code successfully. It is the linker that is having a problem with what you supplied it. This should, in my opinion, happen by default... because it would allow interdependant modules to be grouped in the same directory where they could import each other as needed without any paths having to be specified. I have seen several cases already of modules written to import a file that is part of the same package and as such is stored in the same folder, and almost always the import statement only specifies the unqualified module name. ...making it necessary to add yet another path to the %path% environment variable. Unfortunately, that space is limited. Yes, I can see what you are saying. Basically that the compiler should *also* look for modules by starting relative to the source file's location, and not just rely on the information in sc.ini. Parhaps if you set up a way in build to address a path relative to that of the "current module" ( C maybe?) and suggest that DMD adopt the same convention, it might just happen... some day. :) Also, if a module isn't found elsewhere, perhaps you could have build look aotumatically for it in the path of the file that tried to import it. I can easily do this for build. I'll play around with it for the next release. Personally, I think that location should be checked "first" so that the author of a package can assure that the module in their package will be used... but it would probably be bad to have build do that unless DMD did also, to avoid having them compile "differently". On the other hand... I see no harm in getting build to succede at getting a program to compile in it's own way where DMD alone would otherwise have simply failed. I can make it optional behaviour for Build. -- Derek Parnell Melbourne, Australia http://www.dsource.org/projects/build/ v2.07 released 07/May/2005 http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage 9/05/2005 2:35:26 PM  May 08 2005 "TechnoZeus" <TechnoZeus PeoplePC.com> writes: "Derek Parnell" <derek psych.ward> wrote in message news:11t2nlqdkea3x.1o9ti6nta2mh1$.dlg 40tude.net...
On Sun, 8 May 2005 22:36:07 -0500, TechnoZeus wrote:

"Derek Parnell" <derek psych.ward> wrote in message
news:9dh6z3nm56y3\$.jee04ewtn8su.dlg 40tude.net...

[snip]
Thus you may have to set your current directory to
be the source file's location before compiling it.

Yes, you would think that would work... but here's what I got testing it that
way...

F:\dmd\bin>cd ..\practice\test0

F:\dmd\Practice\test0>..\..\bin\dmd test
OPTLINK (R) for Win32  Release 7.50B1

test.obj(test)
Error 42: Symbol Undefined _D7module01ab
--- errorlevel 1

In defence of Walter's dmd, by giving the command "dmd test" you are asking
two things ... (1) Compile the file 'test.d' - which it did correctly, and
(2) Link 'test.obj', and various modules from 'phobos.lib', 'user32.lib',
and 'kernel32.lib' in order to form an executable. It attempted to link
these together to form the executable but it couldn't succeed because the
linker didn't know where to find the module0 module. To emphasis: the
compiler knew where to find module0.d, but the linker didn't know where to
find module0.obj.

I know that your source code "test.d" contains the line "import module0;"
(or similar). The DMD compiler uses that line during the *compilation*
phase to compile test.d. It did this successfully. The linker does not read
source code so if you want a module to be included in the *linking*
process, you have to tell the linker were to get it from. And that could
theoretically be from either a .obj file or a .lib file. The linker doesn't
know where you might have stored it. In fact, the dmd compiler doesn't know
either. You have to explicitly tell the linker this info. The way to tell
the linker is to place the location on the dmd command line. Either as the
source code name, the object file name or a library name. Thus that is why
you need to use ...

dmd test module0

Simply: The linker needs to know where to find things, and this how you
tell it.

The above command line is actually a short cut for ...

dmd -c test.d
dmd -c module0.d
dmd test.obj module0.obj -oftest.exe

And this is why I created Build. Now all I have to do is ...

build test

and it works out all the details for me.

and also, I usually compile from a context menu... not a command prompt.
In Windows XP, it would be easy to specify a path relative to the original
source file
in a context menu option, but not in Win98... and I can't even think of a way
in
Windows XP of specifying to look for modules in a the same path as the file
that inports them.

I suspect you are merging *compiling* and *linking* into one concept. The
compiler does find the modules' source code successfully. It is the linker
that is having a problem with what you supplied it.

This should, in my opinion, happen by default...
because it would allow interdependant modules to be grouped in the same
directory where they
could import each other as needed without any paths having to be specified.
I have seen several cases already of modules written to import a file that is
part of the same package and
as such is stored in the same folder, and almost always the import statement
only specifies the unqualified module name.
...making it necessary to add yet another path to the %path% environment
variable.   Unfortunately, that space is limited.

Yes, I can see what you are saying. Basically that the compiler should
*also* look for modules by starting relative to the source file's location,
and not just rely on the information in sc.ini.

Parhaps if you set up a way in build to address a path relative to that of the
"current module" ( C maybe?) and suggest that DMD adopt the
same convention, it might just happen... some day.  :)

Also, if a module isn't found elsewhere, perhaps you could have build look
aotumatically for it in the path of the file that tried to import it.

I can easily do this for build. I'll play around with it for the next
release.

Personally, I think that location should be checked "first" so that the author
of a package can assure that the module in their package will be used...
but it would probably be bad to have build do that unless DMD did also, to
avoid having them compile "differently".  On the other hand...
I see no harm in getting build to succede at getting a program to compile in
it's own way where DMD alone would otherwise have simply failed.

I can make it optional behaviour for Build.

--
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build/ v2.07 released 07/May/2005
http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage
9/05/2005 2:35:26 PM

Cool.  That will be great to see.  Not sure how you plan to make it "
optional" but still... I'm looking forward to seeing this.

Yes, I guess technically I am merging compiling and linking into one
concept... but that's because you haven't actually compiled a
working executable until all of it's parts are linked together.  In
other words, linking is actually a part of the full compilation
process, in my opinion.  I'm guessing that at least to some extent
Walter probably feels the same way about it, or the compiler wouldn'
t automatically call the linker... but the integration is incomplete
if the compiler can't tell the linker what it just compiled and
where it put the parts that need to be linked together.  This
information "should" be supplied to the linker by the compiler,
which obviously knows where it put the object files.

As for the case where library files are used instead of source files
and object files, the compiler again "should" also be able to search
for both source files and library files as needed, and choose which
to use based on which are available.  A default search order would
need to be established, but as long as it was consistant, only
special cases would actually require the locations of files to be
specified on the command line.

Likewise, it shouldn't be necessary to specify so many paths in the %
path% variable, since in most cases the path to a module is
specified in the source code relative to either the standard
libraries directory or the directory of the source file requesting
the module.

Personally, this is one of the things I never lined about C and C++
is that each step in the process of building a working application
tends to be treated as if it's completely unrelated to any of the
other steps, and each file used in the process tends to get treated
like it's existance in the project came as a surprise.

What I would really like to see is the ability to specify all of
that "extra" information inside of the D source file, so that it can
be extracted by the compiler and passed on to the linker as needed.

For example...

searching  D\xmp; P\test;
import xyz;
using Windows;
void main(){...

or something like that.

Simply put, it should be possible fot the source code's author to
provide enough information in the source code that all the compiler
needs is the name of the source file, to create a working program.
Such information should never have to be supplied on a command line,
or in an environment variable, or in a make file, or anything like
that... under normal circumstances.

Ideally: It should be possible to write a program of any arbitrary
complexity or simplicity that can be turned from source code to a
simply dragging the icon for the source code onto the icon for the
compiler executable.

Asking alot, I know... but D has some fierce competition,
and I want to see it shine like nothing before it ever has.

I think it has the potential to do go that far.

TZ

May 09 2005
"TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Derek, I was just thinking... don't know if having my system information might
help, but I suppose it couldn't hurt...

--
---
System Information as of: 4/8/2005
OS: Windows 98 A (4.10, Build 2222 English)
BIOS: Award Modular v4.51PG
Processor: Intel Pentium III, ~450MHz
Memory: 62MB RAM
Page File: 1985MB
DirectX Version: DirectX 9.0c
DirectDraw, Direct3D, DirectSound, DirectMusic, DDraw, D3D7, D3D8, D3D9,
Music: All tests were successful.
Display 1 Video card: ATI Rage 128 GL SD AGP (English)
Current Mode: 1024 x 768 (32 bit)(default refresh rate)
Monitor 1: HP D5258A Pavilion M50 Monitor
Display Memory: 16.0 MB
Display 1 Driver Name: ATI2DRAA.DRV Version 4.12.0001.6269 (English)
DDI Version: 7
DDraw Status, D3D Status, AGP Status: Enabled
Display 2 Video card: Cirrus Logic 5446 PCI CL-GD5446 Rev 0
Display 2 Monitor: AcerView 11D
Sound Device: Creative SBPCI Direct Sound Driver Version 4.05.00.1139
(ES1371.VXD)
Sound card name: Creative SB Live! Wave Device
Sound driver: ctmm16.drv
Disk & DVD/CD-ROM Drives: 13.0 GB FAT32 IDE, 114.4 GB FAT32 WD1200LB-22EDA0,
CD-Writer, CD-ROM
---

Apr 30 2005
Georg Wrede <georg.wrede nospam.org> writes:
TechnoZeus wrote:
I'll take a look at your build utility. thanks... however, this is
something that I would much rather see built into the compiler, than

Especially now, that we're pre-1.0, and also for the rest of the year,
it is very important to let Walter concentrate on the compiler.

Thus, whatever Build achieves, should now be considered as "add-on".

Most probably I'm not alone in wishing that the Build utility would
become standard issue with D. It may even really become that, in time.

But for the time being, let's have them as separate issues.

----

PS, Build should have been mentioned in my other post, about the D
Package, containing stuffl like db-io, mango, and whatever. I just
forgot to mention Build there. (Sorry!)

Apr 27 2005
John Reimer <brk_6502 yahoo.com> writes:
Georg Wrede wrote:
TechnoZeus wrote:

I'll take a look at your build utility. thanks... however, this is
something that I would much rather see built into the compiler, than

Especially now, that we're pre-1.0, and also for the rest of the year,
it is very important to let Walter concentrate on the compiler.

Thus, whatever Build achieves, should now be considered as "add-on".

Most probably I'm not alone in wishing that the Build utility would
become standard issue with D. It may even really become that, in time.

But for the time being, let's have them as separate issues.

----

PS, Build should have been mentioned in my other post, about the D
Package, containing stuffl like db-io, mango, and whatever. I just
forgot to mention Build there. (Sorry!)

"Build" is the best D utility to hit the D scene in a long time.  I
believe it's something that D has been needing for ages.  I'm glad Derek
took the plunge and decided to commit so much energy to its developement.

One of the reasons "Build" is (and will continue to be) so successful is
because it parallels D philosophy.  It's there to simplify the
development process.  It prevents excessive programmer concentration on
decidedly mundane, irrelevant tasks (no more learning complicated "make"
rules).  In so doing, it keeps the developer's mind on the task at hand
or simplifies the beginner's ability to work with the new language.

D needs more support tools like this to get the attention of developer
world.  It still has a chance of getting there.  Kudos to Derek and
others for giving it a push in the right direction.

- JJR

PS BTW, my laptop's repaired.  I'm back in business! :-)

Apr 27 2005
"TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:427032E1.2040708 nospam.org...
TechnoZeus wrote:
I'll take a look at your build utility. thanks... however, this is
something that I would much rather see built into the compiler, than

Especially now, that we're pre-1.0, and also for the rest of the year,
it is very important to let Walter concentrate on the compiler.

Thus, whatever Build achieves, should now be considered as "add-on".

Most probably I'm not alone in wishing that the Build utility would
become standard issue with D. It may even really become that, in time.

But for the time being, let's have them as separate issues.

----

PS, Build should have been mentioned in my other post, about the D
Package, containing stuffl like db-io, mango, and whatever. I just
forgot to mention Build there. (Sorry!)

I fully agree.
My opinion remains the same though,
and that is that I would like to see the DMD compiler be
able to compile in most cases with a command that is
simple enough and repeatable enough that it can easily be added
to a Windows context menu to allow compiling from the
menu that comes up when you rignt click on a D file.

I'm not expecting this to happen before D hits version 1.0,
but it would be nice to see as soon as possible,
and I want that fact to be out in the open where it can be
prepared for eventual assimilation through the process of
open discussion.

TZ

Apr 28 2005