www.digitalmars.com         C & C++   DMDScript  

D - Linking == Adventure ? Makefile hell?

reply Ilya Minkov <midiclub 8ung.at> writes:
Hello.

The compiler could (and IMO should) decide which modules need to be 
compiled and linked.

In C it is not possible to identfy from source what files compose the 
project. It is though not unusual that a header file corresponds to a 
compilation unit, this cannot be guaranteed. Say hello to makeheaders 
that i use or Walter's total.h.

In D it's opposite. Any imported unit also has to be linked into 
application.

Besides, erasing units right after compilation is not a very good 
policy. You can always identify what units have changed in source like 
make does.

In C compiled units are often collected into libraries. I'm not exacly 
sure whether it has any technical reason. What i've seen looks like 
this: a library is a separate project. After it's compiled, the library 
is placed in a standard libarary directory and the headerfile must be 
transported to the applications using it, in the case it's changed 
somehow. IMO this only seems to be a simple way to redistribute them in 
compiled form, just because compiling a library is a very painful process.

I propose that D uses a more Delphi-like system:
  - the import statement should make it possible to specify filename 
explicitly, for example:
import system_dependants "sd_win.d";
which would mean that module system_dependants has to be compiled from 
"sd_win.d" or is "sd_win.obj"; (does it make sense?)
  - there should be a standard provision to make modules force link with 
some certain compiled object or library file, which is useful for C 
library import units;
  - if a file is compiled for another time from an unchanged source, but 
with different parameters (like version or debug level), the object file 
doesn't have to be erased, but instead turned into archive, in which 
both the old object file and the new are placed. If code changes then it 
would need to be erased. This might now be implemented by generating 
object files with mangled names (after the first one which should be 
named normally) and using a textfile listing them in place of archive;
  - the compiler should maintain (probably in an INI file) a list of 
directories, in which to search for modules. In practice, traversing a 
list of 100 directories doesn't make a significant impact on compilation 
time;
  - maybe it should be possible to specify in modules what library file 
they should belong to, or better that they should be compiled into the 
library, whose name is the module qualifier, like "collection.***" for 
"module collection.module;".
  - i would like to point out that in Delphi, a unit can import other 
units in 2 different manners: in the interface section, which makes all 
imported declarations promote also upwards to the unit which uses the 
current one, and in the implementation section, hiding them; circular 
unit imports are only allowed in implementation.

All compiled unit names should be possible to deduce from files which 
include them, that is a library name *has* to be one of the "import" 
name parts or be specified explicitly. This way compile time should not 
increase.

The purpose of this all is to:
  - be able to compile a whole project by specifying only its main file;
  - make phrases like "you need to recompile phobos" obsolete, the way 
they belong.

What i wanted to know: does a use of libraries in C instead of a pile of 
object files have any technical sense? Does it simplify linking or not? 
Or is it only done to place all libraries in a single directory?

Another thought is that it should be possible to define linkage type 
aliases, so that one could select the actual one depending on version 
and such.

-i.
Feb 12 2003
parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
I've been thinking about the same lately, because it's just painful to
specify everything in a command line. I even tried to make a program that
parses the `imports´ in a .d file and tried to create a .sh file from it.
The idea was that if there was a .d file available, compile it; if there was
a .obj available, link it. But I couldn't handle the fact of knowing if a
file was in the same path as the main file or if it was somewhere else. That
plus lack of time, made me give up on the idea.
Besides, dmd isn't handling too good the -I option in sc.ini. I thought the
idea was that dmd.exe (or link.exe) would look for .d (or .obj) in the
specified path, but it doesn't. So every single file that I want to import,
I have to move to the path my main file is, and explicitly tell the compiler
"hey, use it!".
About specifying the file name for a given imported module, I support that.
Something else: the compiler can always compare the modified date/time for
the .d and .obj files and decide if it needs to be compiled.

"Ilya Minkov" <midiclub 8ung.at> escribió en el mensaje
news:b2en19$f5f$1 digitaldaemon.com...
| Hello.
|
| The compiler could (and IMO should) decide which modules need to be
| compiled and linked.
|
| In C it is not possible to identfy from source what files compose the
| project. It is though not unusual that a header file corresponds to a
| compilation unit, this cannot be guaranteed. Say hello to makeheaders
| that i use or Walter's total.h.
|
| In D it's opposite. Any imported unit also has to be linked into
| application.
|
| Besides, erasing units right after compilation is not a very good
| policy. You can always identify what units have changed in source like
| make does.
|
| In C compiled units are often collected into libraries. I'm not exacly
| sure whether it has any technical reason. What i've seen looks like
| this: a library is a separate project. After it's compiled, the library
| is placed in a standard libarary directory and the headerfile must be
| transported to the applications using it, in the case it's changed
| somehow. IMO this only seems to be a simple way to redistribute them in
| compiled form, just because compiling a library is a very painful process.
|
| I propose that D uses a more Delphi-like system:
|   - the import statement should make it possible to specify filename
| explicitly, for example:
| import system_dependants "sd_win.d";
| which would mean that module system_dependants has to be compiled from
| "sd_win.d" or is "sd_win.obj"; (does it make sense?)
|   - there should be a standard provision to make modules force link with
| some certain compiled object or library file, which is useful for C
| library import units;
|   - if a file is compiled for another time from an unchanged source, but
| with different parameters (like version or debug level), the object file
| doesn't have to be erased, but instead turned into archive, in which
| both the old object file and the new are placed. If code changes then it
| would need to be erased. This might now be implemented by generating
| object files with mangled names (after the first one which should be
| named normally) and using a textfile listing them in place of archive;
|   - the compiler should maintain (probably in an INI file) a list of
| directories, in which to search for modules. In practice, traversing a
| list of 100 directories doesn't make a significant impact on compilation
| time;
|   - maybe it should be possible to specify in modules what library file
| they should belong to, or better that they should be compiled into the
| library, whose name is the module qualifier, like "collection.***" for
| "module collection.module;".
|   - i would like to point out that in Delphi, a unit can import other
| units in 2 different manners: in the interface section, which makes all
| imported declarations promote also upwards to the unit which uses the
| current one, and in the implementation section, hiding them; circular
| unit imports are only allowed in implementation.
|
| All compiled unit names should be possible to deduce from files which
| include them, that is a library name *has* to be one of the "import"
| name parts or be specified explicitly. This way compile time should not
| increase.
|
| The purpose of this all is to:
|   - be able to compile a whole project by specifying only its main file;
|   - make phrases like "you need to recompile phobos" obsolete, the way
| they belong.
|
| What i wanted to know: does a use of libraries in C instead of a pile of
| object files have any technical sense? Does it simplify linking or not?
| Or is it only done to place all libraries in a single directory?
|
| Another thought is that it should be possible to define linkage type
| aliases, so that one could select the actual one depending on version
| and such.
|
| -i.
|

-------------------------
Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.454 / Virus Database: 253 - Release Date: 2003-02-10
Feb 12 2003
parent Ilya Minkov <midiclub 8ung.at> writes:
It appears that Burton has made a similar effort. His DIG includes=20
"digc", which solves the problem for this library only.

Carlos Santander B. wrote:

 I've been thinking about the same lately, because it's just painful to
 specify everything in a command line. I even tried to make a program th=


at

 parses the `imports=B4 in a .d file and tried to create a .sh file from=


 it.

 The idea was that if there was a .d file available, compile it; if ther=


e was

 a .obj available, link it. But I couldn't handle the fact of knowing if=


 a

 file was in the same path as the main file or if it was somewhere else.=


 That

 plus lack of time, made me give up on the idea.
 Besides, dmd isn't handling too good the -I option in sc.ini. I thought=


 the

 idea was that dmd.exe (or link.exe) would look for .d (or .obj) in the
 specified path, but it doesn't. So every single file that I want to imp=


ort,

 I have to move to the path my main file is, and explicitly tell the com=


piler

 "hey, use it!".
 About specifying the file name for a given imported module, I support t=


hat.

 Something else: the compiler can always compare the modified date/time =


for

 the .d and .obj files and decide if it needs to be compiled.
=20
Feb 15 2003