• Tyro (29/29) Sep 26 2004 In this day and age I shouldn't have to tell the compiler explicitly
• Helmut Leitner (25/62) Sep 26 2004 There is a Windows-alpha of a dmake-utility which does exactly that.
• Burton Radons (20/33) Sep 26 2004 I've thought of adding that kind of functionality to digc many times

Tyro <ridimz_at yahoo.dot.com> writes:

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

Helmut Leitner <helmut.leitner wikiservice.at> writes:

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

Burton Radons <burton-radons shaw.ca> writes:

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.