digitalmars.D.learn - Setting up dmd/build
- Uzair (77/77) Oct 29 2006 Hello,
- Derek Parnell (29/37) Oct 29 2006 This might be telling you something you already know, so please excuse m...
- Uzair (39/39) Oct 31 2006 Derek,
- Derek Parnell (30/71) Oct 31 2006 There is no 'right' way but some things might work better than others...
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
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
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
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