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:








*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
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:








 *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
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:








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


[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

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


 [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

 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:


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