Setting up dmd/build

[Derek Parnell]

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