CompuServe Thread

SYSINCL.DAT

4 messages in this thread
#206864From: SyndesisFeb 3, 1994 5:44 PM
I'm wondering about the accuracy of the documentation for VC 32-bit edition regarding the "SYSINCL.DAT" file. You see a description of it in the online docs under the topic "More information on Include Dependencies" for the Workbench. It claims that this file is rebuilt if it is not found on startup. This text file should contain the filenames of all include files that are not expected to change and should therefore be removed from any automatically generated dependencies. Although I see a SYSINCL.DAT for my VC 16-bit edition, in the BIN directory, there was none for VC 32. I experimented with renaming the MSVC\BIN file to see if the VC 32 somehow found it, and would therefore re-create it, but it didn't. I tried placing a copy of it in the MSVCNT\BIN directory, but when I added entries to it, they had no effect and those files kept arriving in my makefiles. I started poking around with this because of the "feature" that the automatic dependency generator adds all #include lines, even if they are #define'd out. OK, it's a lot to ask for a full preprocessor to scan the dependencies, but at least I wish the SYSINCL.DAT mechanism would work. The docs are not clear about where the SYSINCL.DAT file should be located. It's also not clear whether the exclusion of a file like "exec/exec.h" should be included as EXEC.H or EXEC/EXEC.H. Read action !
#206914From: Michael Meadows [MVP]Feb 3, 1994 8:36 PM
>Although I see a SYSINCL.DAT for my VC 16-bit edition, in the BIN directory, >there was none for VC 32. VC++ for Windows 3.1 (16 bit) uses sysincl.dat in the \msvc\bin directory. VC++ for NT (32 bit) uses msvcincl.dat in the \winnt directory. >It's also not clear whether the exclusion of a file like "exec/exec.h" >should be included as EXEC.H or EXEC/EXEC.H. exec.h 1: SouGreat news, do so it's just a documentation bug.let. 2: What's the proper procedure for reporting bugs? 3: I've also found a problem with the parsing of the 4: string after #includefilename for #include, where the cimompiler acts differently 5: depending on whether the it's using pre-compiled headers or not. 6: /post
#206972From: SyndesisFeb 4, 1994 9:30 AM
Great news, so it's just a documentation buglet. What's the proper procedure for reporting bugs? I've also found a problem with the parsing of the filename for #include, where the compiler acts differently depending on whether it's using pre-compiled headers or not. There is 1 Reply. Read action !
#207002From: Michael Meadows [MVP]Feb 4, 1994 11:58 AM
John, >Great news, so it's just a documentation buglet. What's the proper procedure >for reporting bugs? I'm pretty sure that one has been reported. In general, just post a message to sysop and MS will pick it up. Michael Meadows Read action !