Fix nut-scanner debuglevel#1160
Merged
jimklimov merged 7 commits intonetworkupstools:masterfrom Nov 7, 2021
Merged
Conversation
…e AM_MAKEFLAGS (follows-up to PR networkupstools#1151)
… (avoid double-definition of nut_debug_level among other things)
…-debuglevel Apply the different (upstream) out-of-dir source tracking method with further steps to achieve this PR branch goals: avoid conflict of several copies of nut_debug_level (common.o) in nut-scanner.
aquette
approved these changes
Nov 7, 2021
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
While working on #1157 and #1158 I found that debug-logging from
nut-scanneracted funny: thenut_debug_levelworked correctly for code innut-scanner.c(reacted to-Darguments, etc.) but remained zero for actual scanners.Finally tracked this to the binary (and its part in
libnutscanner) being built with bothlibcommon.laandcommon.cdirectly, and apparently the two same-named objects delivered same-named variables, which apparently confused things.Numerous attempts to rebuild the partial codebase (and in particular to reliably clean and rebuild recipes themselves) led to recipe fixes such as #1151 and #1159 and repercussions in a few other recent PRs.
All for the loss of a horseshoe nail... :)