"Andrew Pennebaker" <[email protected]> wrote in message news:[email protected]... > 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. >
