• Frank Benoit <keinfarbton googlemail.com> Mar 03 2009
• Qian Xu <quian.xu stud.tu-ilmenau.de> Mar 03 2009
• Frank Benoit <keinfarbton googlemail.com> Mar 04 2009

Frank Benoit <keinfarbton googlemail.com> writes:

When doing incremental compilation .di shall help. As I understand it,
it should be possible to compile the modules for a lib and provide the
object files or a library and the .di files.

When doing this, i encounter problems, because now, the user code also
needs the files from the libs setup correctly in the -J path. This makes
the build process more complex. naming conflicts can occur.

To solve this, I want to suggest, that at .di generation the
text-imported files are inserted into the generated .di as a literal. So
the .di file can stand for there own, without the need for any -J option.

Qian Xu <quian.xu stud.tu-ilmenau.de> writes:

Frank Benoit wrote:
 When doing incremental compilation .di shall help. As I understand it,
 it should be possible to compile the modules for a lib and provide the
 object files or a library and the .di files.
 
 When doing this, i encounter problems, because now, the user code also
 needs the files from the libs setup correctly in the -J path. This makes
 the build process more complex. naming conflicts can occur.
 
 To solve this, I want to suggest, that at .di generation the
 text-imported files are inserted into the generated .di as a literal. So
 the .di file can stand for there own, without the need for any -J option.


I feel it strange. The header files I have made (with gdc in Linux) is 
almost the same as the source code (include the implementation).


-- 
Xu, Qian (stanleyxu)
  http://stanleyxu2005.blogspot.com

Frank Benoit <keinfarbton googlemail.com> writes:

Frank Benoit schrieb:
 When doing incremental compilation .di shall help. As I understand it,
 it should be possible to compile the modules for a lib and provide the
 object files or a library and the .di files.
 
 When doing this, i encounter problems, because now, the user code also
 needs the files from the libs setup correctly in the -J path. This makes
 the build process more complex. naming conflicts can occur.
 
 To solve this, I want to suggest, that at .di generation the
 text-imported files are inserted into the generated .di as a literal. So
 the .di file can stand for there own, without the need for any -J option.


Another argument for replacing text-imports with a content-literal is:
The .di has to fulfill a contract, that is it matches to the object file.
If the text-import is done over again by every use of the .di, this
contract is no more guaranteed.