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

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 me.

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 to provide the real location of the mango modules. However, by using

  INIT:BuildImportPath = '"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 = '"C:\\cygwin\home\Uzair\D\include"'

with

  CMDLINE=-I"C:\cygwin\home\Uzair\D\include"

Note:: There is no need for the double backslash here (or in sc.ini either)

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

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

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