www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Setting up dmd/build

reply Uzair <uzair nairang.org> writes:
Hello,

I'm a little unclear on how to set up dmd/bud to build a fairly
simple project. I've downloaded mango, and am using the HttpClient
class to download a webpage.

I'm attaching the sc.ini and build.cfg I'm using. Note that although
these are under my cygwin tree, I am now working purely in cmd.exe,
with the path to dmd/bin at the very front of %PATH%. bud.exe (and
build.cfg) are in dmd/bin, so those are also accessible.

Here's the output from the various things I've tried:

1) Using straight dmd:

C:\cygwin\home\Uzair\dev\rss>dmd rss
rss.d(3): module HttpClient cannot read file
'mango\http\client\HttpClient.d'

2) Using bud:

C:\cygwin\home\Uzair\dev\rss>bud rss
rss.d(3): module HttpClient cannot read file
'mango\http\client\HttpClient.d'

3) Using bud, explicitly trying to specify import and library paths:

C:\cygwin\home\Uzair\dev\rss>bud rss -I..\..\D\include -L..\..\D\lib
OPTLINK (R) for Win32  Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

OPTLINK : Warning 9: Unknown Option : MAP..\..\D\LIB
rss.obj(rss)
 Error 42: Symbol Undefined
__Class_5mango4http6client10HttpClient10HttpClient
rss.obj(rss)
 Error 42: Symbol Undefined
_D5mango4http6client10HttpClient10HttpClient3GetS5ma
ngo4http6client10HttpClient10HttpClient13RequestMethod
rss.obj(rss)
 Error 42: Symbol Undefined
_D5mango4http6client10HttpClient10HttpClient5_ctorFS
5mango4http6client10HttpClient10HttpClient13RequestMethodAaZC5mango4http6client1
0HttpClient10HttpClient
rss.obj(rss)
 Error 42: Symbol Undefined
_D5mango4http6server11HttpHeaders10HttpHeader13Conte
ntLengthS5mango4http6server11HttpHeaders14HttpHeaderName

So, my questions are:
1) What's the best way to clear up the undefined symbol errors? I
thought '-L' to point to the mango.lib file might be the thing to do,
but that obviously didn't work. Also, I'm not clear on why a library
is required at all, since I thought D doesn't have 'header files' and
therefore both declarations and definitions can be 'imported' as
source, ie. from HttpClient.d in this case.
2) My rss.brf (in the same directory as rss.d) has the following in
it, which I thought would be sufficient:
-op
-IC:\cygwin\home\Uzair\D\include\
-IC:\cygwin\home\Uzair\D\dmd\src\phobos\
-IC:\cygwin\home\Uzair\dev\rss\
rss.d
However, as you can see from the output above, that didn't seem to
pass the additional import path (c:\cygwin\home\Uzair\D\include) to
bud.
3) Any suggestions on how best to lay out my project would be
appreciated. I want to leave Mango in a generic place and just
include it as necessary (as I would C++ headers and dll/so's).

Many thanks in advance. I've tried to be as explicit as I could in
describing what I'm doing, I hope it's sufficient (and not
irritating!). Please let me know if there's any additional info I can
provide.

Cheers,

Uzair
begin 644 sc.ini


M<F-<<&AO8F]S( T*3$E.2T--1#U
0;5QB:6Y<;&EN:RYE>&4-" ``
`
end
begin 644 build.cfg
M24Y)5#I,:6)0871H<R`]("<B0SI<7&-Y9W=I;EQH;VUE7%5Z86ER7$1<;&EB
M(B<*24Y)5#I"=6EL9$EM<&]R=%!A=&  /2`G(D,Z7%QC>6=W:6Y<:&]M95Q5
1>F%I<EQ$7&EN8VQU9&4B)PH`
`
end
Oct 29 2006
parent reply "Derek Parnell" <derek nospam.org> writes:
On Mon, 30 Oct 2006 12:59:11 +1100, Uzair <uzair nairang.org> wrote:

 Hello,

 I'm a little unclear on how to set up dmd/bud to build a fairly
 simple project. I've downloaded mango, and am using the HttpClient
 class to download a webpage.

 I'm attaching the sc.ini and build.cfg I'm using. Note that although
 these are under my cygwin tree, I am now working purely in cmd.exe,
 with the path to dmd/bin at the very front of %PATH%. bud.exe (and
 build.cfg) are in dmd/bin, so those are also accessible.
This might be telling you something you already know, so please excuse m= e. I assume you have a line like ... import mango.http.client.HttpClient; in rss.d. In which case, the compiler needs to know where to find this = module. It looks for modules relative to the the paths set by the "-I" = switches (not relative to the file containing the import line). I can see in your sc.ini file that you only have the phobos modules = located by the -I switch, and in the build.cfg file you have attempted t= o = provide the real location of the mango modules. However, by using INIT:BuildImportPath =3D '"C:\\cygwin\home\Uzair\D\include"' you have not told Bud where the files are, but what 'switch' to look for= = that tells where the files are. Assuming that "C:\cygwin\home\Uzair\D\include" is the top of the mango = tree, can I recommend that you replace INIT:BuildImportPath =3D '"C:\\cygwin\home\Uzair\D\include"' with CMDLINE=3D-I"C:\cygwin\home\Uzair\D\include" Note:: There is no need for the double backslash here (or in sc.ini eith= er) Alternatively you can update the sc.ini file to include this path on it'= s = DFLAG line, but be aware that each release of DMD will replace your = updated sc.ini file with the default one from DigitalMars. -- = Derek Parnell
Oct 29 2006
parent reply Uzair <uzair nairang.org> writes:
Derek,

Many thanks for your help!

What I was trying to do, of course, was to keep my
sc.ini and build.cfg as generic as possible and use my
rss.brf as a sort of Makefile.

I do have the import command as you suggest, and I've
fixed my build.cfg to not specify BuildImportPath (I
replace it with the CMDLINE statement, which fixed
things). As it happened, the problem I had with adding
the additional import path to sc.ini was with the way I
was using double quotes -- I was doing this:
DFLAGS="-I% P%\..\src\phobos -
IC:\cygwin\home\Uzair\D\mango"

which is pretty stupid. When I removed the double-
quotes, it worked fine. It also works if I put a set of
double-quotes around each -I clause.

Anyway...I've still got a bit of a problem. Since
build.cfg is sort of a global Makefile, I don't
necessarily want to put the path to mango in it. I
would much rather specify just the path to phobos in my
sc.ini and specify the path to mango in my project's
brf file. My questions are:
1) What's the 'right' way to do this? That is, how
would you organize sc.ini, build.cfg and project.brf
for one of your own projects if it depended on an
external library?
2) Is all this explained somewhere? I've been looking
at the documentation, but I haven't seen a best
practices walkthrough type of thing that explains how
to set up one's D project for bud...maybe I've just
been looking in the wrong place (sorry, I'm quite new
to D).
3) What's the difference between a .brf and a .rsp
file? It seems the .rsp is very well-suited to being
used as a .brf (as long as you're not sending it to
some other computer where the paths to things might be
different...)

Thank you again for your help!

Uzair
Oct 31 2006
parent Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 31 Oct 2006 23:37:46 +0000 (UTC), Uzair wrote:

 Derek,
 
 Many thanks for your help!
You are most welcome.
 What I was trying to do, of course, was to keep my
 sc.ini and build.cfg as generic as possible and use my
 rss.brf as a sort of Makefile.
 
 I do have the import command as you suggest, and I've
 fixed my build.cfg to not specify BuildImportPath (I
 replace it with the CMDLINE statement, which fixed
 things). As it happened, the problem I had with adding
 the additional import path to sc.ini was with the way I
 was using double quotes -- I was doing this:
 DFLAGS="-I% P%\..\src\phobos -
 IC:\cygwin\home\Uzair\D\mango"
 
 which is pretty stupid. When I removed the double-
 quotes, it worked fine. It also works if I put a set of
 double-quotes around each -I clause.
 
 Anyway...I've still got a bit of a problem. Since
 build.cfg is sort of a global Makefile, I don't
 necessarily want to put the path to mango in it. I
 would much rather specify just the path to phobos in my
 sc.ini and specify the path to mango in my project's
 brf file. My questions are:
 1) What's the 'right' way to do this? That is, how
 would you organize sc.ini, build.cfg and project.brf
 for one of your own projects if it depended on an
 external library?
There is no 'right' way but some things might work better than others... (1) Don't touch sc.ini. New releases of DMD are likely to wipe out any changes you make. (2) You can have multiple build.cfg files. Bud looks for them in ... (a) The directory in which Bud is run from (b) Any CFG path you have added. Either through the -BCFPATH switch or BCFPATH environment symbol. (c) The directory in which the compiler is run from. (d) The current working directory. Bud examines each of the build.cfg files found in all these locations. This means that you can place options that effect all runs of Bud into the (a) location, special one-off options in the (b) location, options that effect the compiler in the (c) location and finally options that effect the project in the (d) location. In effect, all these .cfg files are combined in to one 'effective' .cfg file. The 'project.brf' is a good place to add things that are also specific to just the project in question.
 2) Is all this explained somewhere? I've been looking
 at the documentation, but I haven't seen a best
 practices walkthrough type of thing that explains how
 to set up one's D project for bud...maybe I've just
 been looking in the wrong place (sorry, I'm quite new
 to D).
I sort of mention this stuff in the docs re Configuration File. I suppose I could amplify it some more ;-)
 3) What's the difference between a .brf and a .rsp
 file? It seems the .rsp is very well-suited to being
 used as a .brf (as long as you're not sending it to
 some other computer where the paths to things might be
 different...)
The .rsp file is generated each time Bud is run to compile the project. It is created by Bud and passed to the compiler. One does not hand-edit the .rsp or .ksp file. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 1/11/2006 10:40:59 AM
Oct 31 2006