www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Local imports

reply "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
parent reply 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
parent reply "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
parent reply 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
parent reply "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
next sibling parent reply "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:




 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
parent reply 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:




 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
parent reply "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:




 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
parent reply 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
parent reply "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. I hope that is more helpful. Again, thanks for your patience. TZ
Apr 29 2005
parent reply 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\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
Apr 29 2005
parent reply "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
parent reply 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\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

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
next sibling parent reply "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\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

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";".\" LINKCMD=% P%\..\..\dm\bin\link.exe 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 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 thought I had removed it. Sorry I can't be any more hlep. Would if I could. TZ
Apr 30 2005
parent reply 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";".\"
 LINKCMD=% P%\..\..\dm\bin\link.exe
 
 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
 
 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

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 or add f:\dmd\bin (and f:\dm\bin) to your PATH symbol. In the mean time, I'll correct my mistake. -- Derek Parnell Melbourne, Australia 1/05/2005 8:55:05 AM
Apr 30 2005
parent reply "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\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)***
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'
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="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\
 Line 7: LINKCMD=f:\dmd\bin\..\..\dm\bin\link.exe
 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";".\"
 LINKCMD=% P%\..\..\dm\bin\link.exe

 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

 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

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 or add f:\dmd\bin (and f:\dm\bin) to your PATH symbol. 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
parent reply 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
parent reply "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
parent reply 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
next sibling parent "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
prev sibling parent reply "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:

 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
parent reply 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
parent reply "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\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)*** 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' 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="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\ Line 7: LINKCMD=f:\dmd\bin\..\..\dm\bin\link.exe 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
parent reply 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
parent reply "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
parent reply 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
parent reply "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.
 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

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 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
parent reply 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
parent "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
 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

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 working executable by a newbie who just downloaded the compiler by 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
prev sibling parent "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
prev sibling parent reply 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
 only available as an add-on.

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
next sibling parent 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
 only available as an add-on.

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
prev sibling parent "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
 only available as an add-on.

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