Code can now be placed in more deeply-nested directories.
The scaninc build step is modified so that if scaninc fails, the entire build fails on the spot with a detailed error message.
Description
The makefile is altered so that if scaninc fails, we re-run it on the file it failed on and then echo an error message. The error message explicitly states that scaninc is what failed, that it failed because it encountered a fatal error, and that one of the previously printed messages was scaninc's error message. The error message also identifies the file that scaninc was invoked on during the failed run.
Re-running scaninc after a failure and before we echo may not actually be necessary. It was at one point during my random tinkering, in order to get scaninc's own output to reliably display, but I'm not sure it is now, and I lack the expertise (and desire to engage) with makefiles needed to know for sure. Better too many messages than too few, I suppose.
Anyway, the scaninc-related makefile changes should resolve the following problems:
scaninc error messages are not clearly identified as coming from scaninc.
scaninc error messages are not clearly identified as error messages at all, let alone fatal errors implying that some important process has halted.
A scaninc failure doesn't always prevent the build from completing, if the user has previously built the repo properly. They may see unusual behavior (think "having to manually delete *.o files after making certain changes") but things will only blow up once they do a clean build later on, and at that point they'll blow up in spectacular fashion.
Because a scaninc failure doesn't always prevent the build from completing, the messages it produces may be mistaken for warnings rather than fatal errors.
scaninc can choke on things that are valid C code, which only adds to the likelihood that a spurious failure may be mistaken for a warning if the build manages to complete. (Failures I've recently seen include: include directives whose paths contain redundant path separators like "folder//folder"; include directives that point to an empty i.e. zero-length header file; include directives that point to any file whose extension is unknown to scaninc, e.g. .txt or .inl for code fragments used in preprocessor shenanigans.)
The way I tested these changes was by creating a file containing only a semicolon, with file extension inl, and then #includeing it from a source file. The include directive caused a scaninc failure and the build halted with the new error message as intended. Removing the directive allowed the build to proceed again.
Code can now be placed in more deeply-nested directories.
The
scanincbuild step is modified so that ifscanincfails, the entire build fails on the spot with a detailed error message.Description
The makefile is altered so that if
scanincfails, we re-run it on the file it failed on and thenechoan error message. The error message explicitly states thatscanincis what failed, that it failed because it encountered a fatal error, and that one of the previously printed messages wasscaninc's error message. The error message also identifies the file thatscanincwas invoked on during the failed run.Re-running
scanincafter a failure and before weechomay not actually be necessary. It was at one point during my random tinkering, in order to getscaninc's own output to reliably display, but I'm not sure it is now, and I lack the expertise (and desire to engage) with makefiles needed to know for sure. Better too many messages than too few, I suppose.Anyway, the
scaninc-related makefile changes should resolve the following problems:scanincerror messages are not clearly identified as coming fromscaninc.scanincerror messages are not clearly identified as error messages at all, let alone fatal errors implying that some important process has halted.scanincfailure doesn't always prevent the build from completing, if the user has previously built the repo properly. They may see unusual behavior (think "having to manually delete *.o files after making certain changes") but things will only blow up once they do a clean build later on, and at that point they'll blow up in spectacular fashion.scanincfailure doesn't always prevent the build from completing, the messages it produces may be mistaken for warnings rather than fatal errors.scaninccan choke on things that are valid C code, which only adds to the likelihood that a spurious failure may be mistaken for a warning if the build manages to complete. (Failures I've recently seen include: include directives whose paths contain redundant path separators like "folder//folder"; include directives that point to an empty i.e. zero-length header file; include directives that point to any file whose extension is unknown toscaninc, e.g. .txt or .inl for code fragments used in preprocessor shenanigans.)The way I tested these changes was by creating a file containing only a semicolon, with file extension
inl, and then#includeing it from a source file. The include directive caused ascanincfailure and the build halted with the new error message as intended. Removing the directive allowed the build to proceed again.Discord contact info
@davidjcobb