In this day and age I shouldn't have to tell the compiler explicitly what I want to compile. I've already specified what I want to use in my source by using the import statement, so the compiler knows exactly what needs to be linked in. It also knows where to find this material (location of source code).

Of course the linker works with object files, so if it is unable to find  what it needs in a library or object file it should be smart enough to have the compiler produce that file from source.

In effect, I should be able to do the following and obtain the desired result.

<code>
source.d
==========
module source;
class foo{...}

main.d
==========
import source;
int main() {
  foo bar = new foo;
  return 0;
}
</code>

c:\dmd main

Outcome:
  compiles and links both main.d and source.d

Am I way off base here?
Is this unobtainable?
Andrew Edwards

Tyro wrote:
> 
> In this day and age I shouldn't have to tell the compiler explicitly what I want to compile. I've already specified what I want to use in my source by using the import statement, so the compiler knows exactly what needs to be linked in. It also knows where to find this material (location of source code).
> 
> Of course the linker works with object files, so if it is unable to find
>   what it needs in a library or object file it should be smart enough to
> have the compiler produce that file from source.
> 
> In effect, I should be able to do the following and obtain the desired result.
> 
> <code>
> source.d
> ==========
> module source;
> class foo{...}
> 
> main.d
> ==========
> import source;
> int main() {
>    foo bar = new foo;
>    return 0;
> }
> </code>
> 
> c:\dmd main
> 
> Outcome:
>    compiles and links both main.d and source.d
> 
> Am I way off base here?
> Is this unobtainable?
> Andrew Edwards

There is a Windows-alpha of a dmake-utility which does exactly that.

dmake analyzes the dependencies, looks if existing obj files are up to date and generates an response file to call dmd to do the rest.

Modules have to be correctly positioned and named in source-trees.

For a beta it
  - has to be tested more thoroughly
  - possible problems with cyclic dependencies have to be looked at
  - linux portability added (just 3 functions needed, e. g. FileGetTime)
  - checking/adding support for version-statements
  - add support for reading d-roots from config files

If anyone is interested (maybe help on these), drop me an e-mail
and I'll then send the preliminary code (it's small, 740 lines, much
of it drawn from digc, stripped down and enhanced).

Because I'm short on development time it will take another 10-20 work hours or 4-6 weeks of real time until beta (if no-one pushes me).

Working with unified source trees without caring about library and project borders would create a very open and fluid situation, easing community contributions of all kinds.

At least that's the goal. Of course, it would make life for newcomers
much easier, who would just have to write some hiscode.d, import some modules
from anywhere and call "dmake hiscode" to arrive at an executable.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

Tyro wrote:
> In this day and age I shouldn't have to tell the compiler explicitly what I want to compile. I've already specified what I want to use in my source by using the import statement, so the compiler knows exactly what needs to be linked in. It also knows where to find this material (location of source code).
> 
> Of course the linker works with object files, so if it is unable to find  what it needs in a library or object file it should be smart enough to have the compiler produce that file from source.
> 
> In effect, I should be able to do the following and obtain the desired result.

I've thought of adding that kind of functionality to digc many times over the years.  I haven't for a number of reasons:

- Sometimes modules are linked by tertiary associations.  For example, a filter which registers in a static constructor has no association through import.

- The main problem is that wildcards aren't expanded by the shell in Windows.  digc does this.

- It would make compilation of multiple codependent libraries difficult.  We would have to add fence arguments to keep the command-line from pulling in files from certain directories.

I think the current way works just fine.  When I'm writing a one-off program all I need to have as the compilation argument is:

    /dmd/bin/digc *.d -exe=project -then-run

And for large libraries with a dozen directories:

    /dmd/bin/digc -build=net -then=program

So it would actually be /more/ effort to remember what my main filename is called.  :)

> Am I way off base here?

Yeah, wrong target; dmd is a blunt instrument by design.  It's intended to be at the bottom end of a toolchain, not the top.