shebang launcher for D programs

[Chris Nicholson-Sauls]

Andrei Alexandrescu (See Website For Email) wrote:
> Bruno Medeiros wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> Anders F Björklund wrote:
>>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>>
>>>>> In short, rundmd does what rdmd does but works on multi-module 
>>>>> programs.
>>>>>
>>>>> I suspect other people have written similar scripts, but just in 
>>>>> case, I thought I'd ask. If people are interested, I'll be glad to 
>>>>> comb the script a little and post it here.
>>>>
>>>> Rebuild has a similar feature (-exec), but it's a program not a script.
>>>> I think build/bud also did, but I had problems with it and GDC/Tango...
>>>
>>> Sounds great. Where is rebuild? (Bud aka build is easy to find on 
>>> dsource.org).
>>>
>>>> Not sure how you pass runtime / program arguments over to it, though ?
>>>> But it does parse and compile all the imported modules for the program.
>>>
>>> (The way I do it is simple but ambiguous - any flags that come before 
>>> the program name are passed to dmd, and any stuff that comes after 
>>> the program name is considered that program's arguments. The program 
>>> name is the first thing without a leading "-".)
>>>
>>> I think such a tool should be part of the standard distribution - 
>>> it's very, very useful.
>>>
>>>
>>> Andrei
>>
>> I agree, from first hand experience. I've made some D scripts myself, 
>> and there are some modules that I use often in such D scripts, such 
>> that I had to create a shell script wrapper to automatically include 
>> those module libs in D script compilation. (although I guess I could 
>> have put them in the shebang line as well, but that was more annoying)
> 
> Finally :o). I was surprised by the responses to this topic, which
> basically revolved around the theme "Tool X and tool Y could be changed
> to do that". For me, the availability of a simple shebang script that
> takes care of'em all made a very inconvenient problem just disappear,
> and I also think that making such a tool part of the standard
> distribution would reduce the entry barrier to D enormously.
> 
> Which brings me to the question: what is the project style with D that
> people use? What tool(s) do you use, and in what sequence?  The way I
> currently do things is, I have a bunch of modules in a directory tree
> and I import them in whichever programs I'm writing. I edit the program,
> save it, and then just start it (the .d program; the fact that object
> files and a binary executable are generated is entirely transparent) 
> from the command line. I never need to explicitly compile or build 
> anything, and I only see any messages (such as gcc's link command) when 
> the program has an error.
> 
> 
> Andrei

I do much the same (Cashew on dsource started out as a clip from my personal lib) although 
I sometimes go a step further, where whole apps are in the tree so to say.  For example 
the entire Bovis application is under a bovis.* package -- including the main program 
file, bovis.Main -- which makes my life easier when working on the companion program Guru, 
it just imports bovis.db.* and suddenly has just as much access to the Bovis database 
format as the main program does.  Useful since Guru is supposed to be a utility for 
expediating new db development and/or db tweaking.

Beyond that, its just a collection of .brf files I pass to build, and the occasional 
script to run multiple builds.  (Such as Cashew's buildall which compiles a debug .lib, a 
release .lib, and the docs, and runs my little docfix utility to make the docs work with a 
slightly modified CanDyDoc the way I prefer.)  Ultimately its not far off from your own 
pattern.

-- Chris Nicholson-Sauls