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.

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 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.