digitalmars.D - Compilation of .di needes the imported file and -J setup correctly
- Frank Benoit (9/9) Mar 03 2009 When doing incremental compilation .di shall help. As I understand it,
- Qian Xu (6/17) Mar 03 2009 I feel it strange. The header files I have made (with gdc in Linux) is
- Frank Benoit (5/16) Mar 04 2009 Another argument for replacing text-imports with a content-literal is:
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
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
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