Nick, thanks for the in-depth explanation of compilation with C and D.<br><br>Other shebanged languages <i>do</i> have the argument limitation problem. One way to deal with it is to use <a href="http://rosettacode.org/wiki/Multiline_shebang">multiline shebangs</a>. They're especially helpful for doing <a href="http://rosettacode.org/wiki/Scripted_Main">scripted main</a>, running main() when the script is run, but not when the code is imported by other code.<br>

<br>For example, since Clojure is in Java Land, it expects a class name rather than a filename, so you have to do shell trickery just to get the basename.<br><br>Clojure<br>
<br>
<pre class="clojure highlighted_source"><span class="st0">":"</span><span class="co1">;exec clj -m `basename $0 .clj` $0 ${1+"$@"}</span><br><span class="st0">":"</span><span class="co1">;exit</span></pre>


<br>The CLISP implementation of Common Lisp drops the program name as an argument, so you have to forcibly add it back. Unfortunately, each CL implementation has its own program name, <i>and</i> command line semantics, so you have to rewrite this one for the particular CL implementation on your machine.<br>

<br>Common Lisp<br><br><pre class="lisp highlighted_source">#<span class="sy0">!</span>/bin/sh<br>#<span class="sy0">|</span><br>exec clisp -q -q $0 $0 $<span class="br0">{</span><span class="nu0">1</span>+<span class="st0">"$@"</span><span class="br0">}</span><br>

exit<br><span class="sy0">|</span>#</pre><br>Chicken Scheme<br><br><pre class="scheme highlighted_source">#<span class="sy0">!/</span>bin<span class="sy0">/</span>sh<br><span class="coMULTI">#|<br>exec csi -ss $0 ${1+"$@"}<br>

exit<br>|#</span></pre><br>Emacs Lisp<br><br><pre class="lisp highlighted_source"><span class="sy0">:</span><span class="co1">;exec emacs -batch -l $0 -f main $*</span></pre>Smalltalk<br><br><pre class="smalltalk highlighted_source">

<span class="coMULTI">"exec"</span> <span class="coMULTI">"gst"</span> <span class="coMULTI">"-f"</span> <span class="coMULTI">"$0"</span> <span class="coMULTI">"$0"</span> <span class="coMULTI">"$@"</span><br>

<span class="coMULTI">"exit"</span></pre><br>The trick is to find a way to comment the shebang lines so that sh sees them but not your programming language. But the real trouble is discovering the secret syntax for this; when you have to resort to multiline shebangs, that's an indication that scripting/CLI/POSIX is an incredibly low priority, so developers A) don't know such obscure syntax and B) don't understand why anyone would want to script on the command line. Common Lispers tell you "there's no reason to use bash when you've got the CL repl". Smalltalkers say "just use the Squeak VM GUI." And Free Pascalers remark "Scripting? You kids get off my lawn!"<br>

<br>Language-specific IDEs are neat, but I like using a language-agnostic development environment: a text editor and a shell, and I like being able to dot-slash my scripts: ./script if at all possible.<br><br>So three cheers for rdmd!<br clear="all">

<div><br></div>Cheers,<div><br></div><div>Andrew Pennebaker</div><div><a href="http://www.yellosoft.us" target="_blank">www.yellosoft.us</a></div><br><div class="gmail_quote">On Thu, Oct 27, 2011 at 11:17 PM, Nick Sabalausky <span dir="ltr"><a@a.a></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">"Andrew Pennebaker" <<a href="mailto:andrew.pennebaker@gmail.com">andrew.pennebaker@gmail.com</a>> wrote in message<br>


</div>news:mailman.550.1319767813.24802.digitalmars-d@puremagic.com...<br>
<div class="im">> Nick, thanks for the info. I'm upgrading my Homebrew D installation now.<br>
> What's the point of -Ipath for dmd if you still have to specify the actual<br>
> files in the path?<br>
><br>
<br>
</div>It has to do with D's C/C++ legacy, and the traditional C/C++ build model.<br>
In C/C++, you can compile difference sources separately, and *then* link<br>
them together - in fact, that's the old traditional way to do it:<br>
<br>
(I might not have these commands correct, I don't use gcc much)<br>
$ gcc -c -I~/ -I~/zlib a.c  # compile to a.o, imports/headers can be found<br>
in ~/ and ~/zlib<br>
$ gcc -c ~/b.c   # compile to b.o<br>
$ gcc -c ~/c.c   # compile to c.o<br>
$ ld -of app a.o b.o c.o ~/zlib/zlib.lib   # link together into app, along<br>
with pre-built zlib<br>
$ ./app   # run app<br>
<br>
D retains that ability:<br>
$ dmd -c -I~/ -I~/zlib a.d   # compile to a.o, imports/headers can be found<br>
in ~/ and ~/zlib<br>
$ dmd -c ~/b.d   # compile to b.o<br>
$ dmd -c ~/c.d   # compile to c.o<br>
$ dmd -ofapp a.o b.o c.o ~/zlib/zlib.lib   # link together into app, along<br>
with pre-built zlib<br>
$ ./app   # run app<br>
<br>
And as a shortcut, modern C/C++ and D compilers offer the ability to<br>
simplify that all into one command:<br>
<br>
$ dmd -ofapp -I~/zlib a.d ~/b.d ~/c.d ~/zlib/zlib.lib  # shortcut for the<br>
above statements<br>
<br>
But the old way is still possible becuause sometimes it can be useful (for<br>
instance, if a b and c are all in different languages, or if you want them<br>
each compiled with different settings, or to speed up long C/C++ compile<br>
times by compiling different parts on different machines).<br>
<br>
So that leads to this:<br>
<br>
Regardless of whether you do that in C/C++ or D: Suppose 'a' imports 'b',<br>
and inside 'a' you call a function from 'b'. If you've told it to *only*<br>
compile 'a' and not 'b' (because you intend to do it all separately) how<br>
does the compiler know that function you're using actually exists if you've<br>
only given it 'a'? Or if 'a' uses a class defined in 'b', how does the<br>
compiler know what members the class has if you only told it to compile 'a'?<br>
It has to find 'b', open it, and check. That's what -Ipath is for, so it<br>
knows where to find 'b' so it can find out what's in 'b', so that it can<br>
compile 'a' regardless of whether or not it's actually compiling 'b' as<br>
well.<br>
<br>
Of course, in most cases with D, all of that "one at a time" junk is just a<br>
pointless PITA, so fortunately we have RDMD to find all the .d files and<br>
just shove them all off to be compiled. So this:<br>
<br>
$ dmd -ofapp -I~/zlib a.d ~/b.d ~/c.d ~/zlib/zlib.lib<br>
<br>
Becomes this:<br>
<br>
$ rdmd --build-only -ofapp -I~/zlib ~/zlib/zlib.lib a.d<br>
<br>
Note that ~/b.d and ~/c.d were omitted because RDMD will just find them<br>
itself, thanks to the -Ipath, and pass them all off to DMD to be compiled.<br>
<br>
Why can't DMD just do this itself, even just as an option? It could, and<br>
many people here wish it did. Maybe it even will someday. But right now it<br>
doesn't, so we have RDMD for that.<br>
<div class="im"><br>
<br>
> I'm not sure if this is the right mailing list, but I'd really like to see<br>
> rdmd using the $DFLAGS environment variable like dmd does.<br>
<br>
</div>Yea, that would be nice.<br>
<div class="im"><br>
> For now, I'll use<br>
> your handy shebang tip.<br>
><br>
> Can future versions of rdmd turn on --shebang by default? I can't think of<br>
> a<br>
> reason to give coders the ability to not support shebang options.<br>
><br>
<br>
</div>If it did that, then it won't work on the commandline anymore. :(  IIRC, the<br>
problem is that with shebang scripts, all the args get passed in together as<br>
*one* large arg.<br>
<br>
But maybe there's a way to detect what's happening that isn't too<br>
unreliable...?<br>
<br>
Hell, other Unix apps don't seem to have this sort of problem, how the heck<br>
to they handle it?<br>
<div><div></div><div class="h5"><br>
> Jesse, aye, DFLAGS in dmd.conf appears to override the default rather than<br>
> append to the default. And that's just silly.<br>
><br>
<br>
<br>
<br>
</div></div></blockquote></div><br>