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.

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

It appears that Burton has made a similar effort. His DIG includes "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 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.
>