Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Makefile: deeper folder nesting support; fail build when SCANINC fails #1951

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

DavidJCobb
Copy link

@DavidJCobb DavidJCobb commented Nov 12, 2023

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.

Discord contact info

@davidjcobb

Code can now be placed in more deeply-nested directories.

Modified the SCANINC step of the build so that if SCANINC fails, the entire build fails on the spot.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant