www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Compilation of .di needes the imported file and -J setup correctly

reply 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.
Mar 03 2009
next sibling parent 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
Mar 03 2009
prev sibling parent 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.
Mar 04 2009