D packages, include directories, and rdmd

[Nick Sabalausky]

"Andrew Pennebaker" <andrew.pennebaker at gmail.com> wrote in message 
news:mailman.550.1319767813.24802.digitalmars-d at puremagic.com...
> Nick, thanks for the info. I'm upgrading my Homebrew D installation now.
> What's the point of -Ipath for dmd if you still have to specify the actual
> files in the path?
>

It has to do with D's C/C++ legacy, and the traditional C/C++ build model. 
In C/C++, you can compile difference sources separately, and *then* link 
them together - in fact, that's the old traditional way to do it:

(I might not have these commands correct, I don't use gcc much)
$ gcc -c -I~/ -I~/zlib a.c  # compile to a.o, imports/headers can be found 
in ~/ and ~/zlib
$ gcc -c ~/b.c   # compile to b.o
$ gcc -c ~/c.c   # compile to c.o
$ ld -of app a.o b.o c.o ~/zlib/zlib.lib   # link together into app, along 
with pre-built zlib
$ ./app   # run app

D retains that ability:
$ dmd -c -I~/ -I~/zlib a.d   # compile to a.o, imports/headers can be found 
in ~/ and ~/zlib
$ dmd -c ~/b.d   # compile to b.o
$ dmd -c ~/c.d   # compile to c.o
$ dmd -ofapp a.o b.o c.o ~/zlib/zlib.lib   # link together into app, along 
with pre-built zlib
$ ./app   # run app

And as a shortcut, modern C/C++ and D compilers offer the ability to 
simplify that all into one command:

$ dmd -ofapp -I~/zlib a.d ~/b.d ~/c.d ~/zlib/zlib.lib  # shortcut for the 
above statements

But the old way is still possible becuause sometimes it can be useful (for 
instance, if a b and c are all in different languages, or if you want them 
each compiled with different settings, or to speed up long C/C++ compile 
times by compiling different parts on different machines).

So that leads to this:

Regardless of whether you do that in C/C++ or D: Suppose 'a' imports 'b', 
and inside 'a' you call a function from 'b'. If you've told it to *only* 
compile 'a' and not 'b' (because you intend to do it all separately) how 
does the compiler know that function you're using actually exists if you've 
only given it 'a'? Or if 'a' uses a class defined in 'b', how does the 
compiler know what members the class has if you only told it to compile 'a'? 
It has to find 'b', open it, and check. That's what -Ipath is for, so it 
knows where to find 'b' so it can find out what's in 'b', so that it can 
compile 'a' regardless of whether or not it's actually compiling 'b' as 
well.

Of course, in most cases with D, all of that "one at a time" junk is just a 
pointless PITA, so fortunately we have RDMD to find all the .d files and 
just shove them all off to be compiled. So this:

$ dmd -ofapp -I~/zlib a.d ~/b.d ~/c.d ~/zlib/zlib.lib

Becomes this:

$ rdmd --build-only -ofapp -I~/zlib ~/zlib/zlib.lib a.d

Note that ~/b.d and ~/c.d were omitted because RDMD will just find them 
itself, thanks to the -Ipath, and pass them all off to DMD to be compiled.

Why can't DMD just do this itself, even just as an option? It could, and 
many people here wish it did. Maybe it even will someday. But right now it 
doesn't, so we have RDMD for that.


> I'm not sure if this is the right mailing list, but I'd really like to see
> rdmd using the $DFLAGS environment variable like dmd does.

Yea, that would be nice.

> For now, I'll use
> your handy shebang tip.
>
> Can future versions of rdmd turn on --shebang by default? I can't think of 
> a
> reason to give coders the ability to not support shebang options.
>

If it did that, then it won't work on the commandline anymore. :(  IIRC, the 
problem is that with shebang scripts, all the args get passed in together as 
*one* large arg.

But maybe there's a way to detect what's happening that isn't too 
unreliable...?

Hell, other Unix apps don't seem to have this sort of problem, how the heck 
to they handle it?

> Jesse, aye, DFLAGS in dmd.conf appears to override the default rather than
> append to the default. And that's just silly.
>