Andrei Alexandrescu (See Website For Email) wrote:
>>
>>
>> So I think it's fair to have the rdmd program default to using dmd/gdmd,
>> even if bud/rebuild do exist as an optional (and recommended) D add-on ?
> 
> Well fair of course it is, it's IMHO just not enough. I strongly believe that an rdmd that automatically figures out dependencies must be part of the standard D distribution.

A lot of us feel the same way.  And since DMD does this anyway, adding a compilation feature doesn't seem too onerous.


Sean

Andrei Alexandrescu (See Website For Email) wrote:

>> So I think it's fair to have the rdmd program default to using dmd/gdmd,
>> even if bud/rebuild do exist as an optional (and recommended) D add-on ?
> 
> Well fair of course it is, it's IMHO just not enough. I strongly believe that an rdmd that automatically figures out dependencies must be part of the standard D distribution.

Seeing as how rebuild is based on the DMD sources, I don't think this is
impossible. But if it complicates the release of the compilers, it might as well be stand-alone ? As in: installing Bud or Rebuild separately...

In the end it is up to Walter if he wants to include the functionality in the regular DMD compiler or leave it as a "third-party opportunity" ?
The pragmatic approach is rdmd in the main, and bud/rebuild as add-ons.

>> Currently this can be done by recompiling rdmd... (assuming here that
>> the rdmd source code eventually gets included in the DMD distribution)
>>
>> Maybe it could even use a configuration file for those two options.
>> (i.e. a simple INI file for overriding --compiler and --tmpdir ?)
> 
> If you make the code open source, I'd be glad to hack into it to make it do the deed without relying on any other tool.

The code is public domain, but if it's not included it can be somewhat
hard to find... It was released on the digitalmars.D.announce newsgroup:

rdmd 1.0 (DMD/linux) digitalmars.D.announce:2668, 13 Feb 2006
rdmd 1.1 (DMD/Windows) digitalmars.D.announce:2673, 14 Feb 2006

As far as I can tell it (rdmd binaries) was introduced with DMD 0.148 ?
I posted my modified rdmd code at http://www.algonet.se/~afb/d/rdmd.d:

rdmd "1.2" (GDC/Unix) digitalmars.D.announce:8010, 21 Mar 2007

But I was only talking about changing "rdmd" so that it calls upon an external "bud" or "rebuild" program, as opposed to "dmd" or "gdmd"...

--anders

Andrei Alexandrescu (See Website For Email) wrote:
> Bruno Medeiros wrote:
> 
> 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

Well, I have two distinct scenarios.
1: D "scripts", which are small, one-file programs, only linked to some common utility shell scripting modules. I started using these as an alternative to bash scripting which didn't scale well (if at all, lol).

2: Normal D programs. I don't have any actual D project, but for bigger apps (multi-modules) I use a simple Ant script that wraps around bud. D code is edited in Eclipse, and also launched from Eclipse. This is also my sandbox where I do test code and try features and stuff (even if just on one file).

I, like many others here, have also always recognized the great advantage of having the functionality of build (automatically include dependencies) and rdmd (create temporary files in temporary dirs, automatically run the target program) into the standard dmd distribution.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Daniel Keep wrote:
> 
> I'm not sure associating .d files with rdmd under Windows would do much
> good.  One problem is that Windows makes a distinction between console
> and window apps, so either your console apps never output anything, or
> your window apps always have a console window lying around.  Python
> solves this by having python.exe and pythonw.exe (the latter is a window
> app, thus it has no console window), and using two extensions: .py and .pyw.
> 

Hum, it's exactly like Java then (java.exe and javaw.exe) :)

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D