www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Autolink on import

reply 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
Sep 26 2004
next sibling parent 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
Sep 26 2004
prev sibling parent 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.
Sep 26 2004