I've been spoiled by scripting languages where modules just get imported on the fly from the same directory or the "lib" path. So in D, let's suppose I have 2 reusable libraries LibA and LibB and two programs ProgA and ProgAB, where the prog names indicate which libraries they use. (I'm on MS Windows.)

(Btw I don't think I'm interested in DLLs--I think it's LIBs I'm
asking about.)

So the files could be:
LibA/*.d
LibB/*.d
ProgA/*.d  -- wants to import modules in LibA
ProgAB/*.d  -- wants to import modules in LibA and LibB

How do I go about building all of this and telling ProgA where LibA even exists (and that it should be built)?

Are people using makefiles, or digc, or slamming everything on one dmd command line, or something else?

Subquestion: Does the answer to the above need enhancement for nested packages?

MyLibs\
	Web\
		Utils.d
		...
	Text\
		...
	Collections\
		...
MyProg1\
	Prog.d

where I would want to say in Prog.d:

import MyLibs.Web.Utils;
// use the utils...


And does Utils.d have to say "module MyLibs.Web.Utils;" at the top, or can it just say "module Utils"?

What if MyLibs\Web\Utils.d want to import/use MyLibs\Text\Foo?


-Chuck

On Wed, 17 Aug 2005 03:51:45 -0700, Chuck Esterbrook <Chuck.Esterbrook@gmail.antispam.com> wrote:
> I've been spoiled by scripting languages where modules just get
> imported on the fly from the same directory or the "lib" path. So in
> D, let's suppose I have 2 reusable libraries LibA and LibB and two
> programs ProgA and ProgAB, where the prog names indicate which
> libraries they use. (I'm on MS Windows.)
>
> (Btw I don't think I'm interested in DLLs--I think it's LIBs I'm
> asking about.)
>
> So the files could be:
> LibA/*.d
> LibB/*.d
> ProgA/*.d  -- wants to import modules in LibA
> ProgAB/*.d  -- wants to import modules in LibA and LibB
>
> How do I go about building all of this and telling ProgA where LibA
> even exists (and that it should be built)?
>
> Are people using makefiles, or digc, or slamming everything on one dmd
> command line, or something else?

I am personally using 2 things:

1. "build" - http://www.dsource.org/projects/build/
2. A custom sc.ini, eg.

C:\Library\D\dmd\bin>more sc.ini
[Version]
version=7.51 Build 020

[Environment]
LIB="%@P%\..\lib";\dm\lib
DFLAGS="-I%@P%\..\src\phobos;%@P%\..\..\src"
LINKCMD=%@P%\..\..\dm\bin\link.exe

Note the DFLAGS line, note the "%@P%\..\..\src" path, this path is the root of my source tree relative to the "C:\Library\D\dmd\bin" directory, it's full path is of course "C:\Library\D\src".

What this means is that if I say "import lib.foo" it will look in the "C:\Library\D\src\lib" directory for a file called "foo.d". I simply place all my reusable source in folders in that path, name them appropriately and import to my hearts content.

If you want to set a path on a per project basis then I imagine you can just place the -I etc on the command line call to dmd, or build.

> Subquestion: Does the answer to the above need enhancement for nested
> packages?
>
> MyLibs\
> 	Web\
> 		Utils.d
> 		...
> 	Text\
> 		...
> 	Collections\
> 		...
> MyProg1\
> 	Prog.d
>
> where I would want to say in Prog.d:
>
> import MyLibs.Web.Utils;
> // use the utils...

Assuming you add the root folder, i.e. the one that MyLibs is in to the sc.ini then this should work.

> And does Utils.d have to say "module MyLibs.Web.Utils;" at the top, or
> can it just say "module Utils"?

"module MyLibs.Web.Utils;"

> What if MyLibs\Web\Utils.d want to import/use MyLibs\Text\Foo?

Add "import MyLibs.Text.Foo" to it.

Regan

On Wed, 17 Aug 2005 03:51:45 -0700, Chuck Esterbrook wrote:

> I've been spoiled by scripting languages where modules just get imported on the fly from the same directory or the "lib" path. So in D, let's suppose I have 2 reusable libraries LibA and LibB and two programs ProgA and ProgAB, where the prog names indicate which libraries they use. (I'm on MS Windows.)
> 
> (Btw I don't think I'm interested in DLLs--I think it's LIBs I'm
> asking about.)
> 
> So the files could be:
> LibA/*.d
> LibB/*.d
> ProgA/*.d  -- wants to import modules in LibA
> ProgAB/*.d  -- wants to import modules in LibA and LibB
> 
> How do I go about building all of this and telling ProgA where LibA even exists (and that it should be built)?
> 
> Are people using makefiles, or digc, or slamming everything on one dmd command line, or something else?

I use the Build utility that I wrote. It sorts this stuff out for me.

> Subquestion: Does the answer to the above need enhancement for nested packages?
> 
> MyLibs\
> 	Web\
> 		Utils.d
> 		...
> 	Text\
> 		...
> 	Collections\
> 		...
> MyProg1\
> 	Prog.d
> 
> where I would want to say in Prog.d:
> 
> import MyLibs.Web.Utils;
> // use the utils...
> 
> 
> And does Utils.d have to say "module MyLibs.Web.Utils;" at the top, or can it just say "module Utils"?
>
> What if MyLibs\Web\Utils.d want to import/use MyLibs\Text\Foo?

The thing to remember is that the path specified in the module statement is relative to the current directory you have started the compiler with, or relative to one of the paths in the -I switches.

In the situation above, I would add MyLibs to the CMDLINE= line in the build.cfg file, and set the module startment to "module Web.Utils;". That way, when Build looks for the Utils.d file it will search in "MyLibs\Web" for it. Set the module statement in Foo.d to "Text.Foo;" and Build will also find that too under the MyLibs parent folder.

So after updating the build.cfg file all you have to do is ...

   cd MyProg
   build Prog

and it will find everything.

My build.cfg file looks like this ...
#-------------------------
CMDLINE=-info           # Show the version of build

CMDLINE=-Iz:\d_proj\build\trunk\source
CMDLINE=-Iz:\dlibs

LIBCMD=%@D%\..\..\dm\bin\lib.exe

BMD=@S\djp.bmd

[dbg]
CMDLINE=-unittest --release --inline -g -w -full
CMDLINE=-T{Target}_{Group}

[prod]
CMDLINE=--unittest --debug* --g --w -release -inline -full
CMDLINE=-T{Target}_{Group}
#-------------------------

-- 
Derek Parnell
Melbourne, Australia
17/08/2005 11:04:47 PM

Regan Heath wrote:

> 
> If you want to set a path on a per project basis then I imagine you can  just place the -I etc on the command line call to dmd, or build.

This is how I do it. I have a template Build Response File I use for each new project and usually maintain two versions - one for debug and another for release builds. I pass the import path on through the BRF files. For most projects (things I will never distribute as source), I use common import and lib directories, but for projects I might consider releasing in the future (two I'm working on right now) I create import and lib sudirectories in the project root and copy over the ones I'm using.

Thanks to everyone who responded.

-Chuck