Mats Wichmann
2018-07-17 14:23:19 UTC
I brought this subject up on irc, wanted to bring it here for some
framing before filing a github issue.
A call to an sconscript which is not found is a warning, not an error.
To me that sounds dangerous. In fact, the project I'm working on has
some problems due to this, though it's largely our fault (a non-core
build which will not be executed directly, rather handed off to another
buildystem which in the end calls scons again, but only after moving
pieces around to craft a custom setup. PLEASE don't ask, it's too painful).
On initial discussion on irc, there was some sentiment that turning this
case fatal might be a good idea, with developers who don't want it to be
fatal able to trap the exception and proceed; but as I've poked around
in the code, it's clearly intentional: there are test cases to make sure
the warning is issued as expected, and a command-line warning to turn
on/off the printing of a warning message for this - but not one to make
it an error.
So I'm happy to to file a bug on changing this behavior if people agree
that's the right approach, but that feels like it might be an "API
change" - at least a change in long-standing behavior.
So how about this as an alternative? Can we add a mechanism to
selectively or all-in treat warnings as errors? If so I'd propose a
concept similar to gcc, such that:
-Werror - treat all warnings as errors
-Werror=XXX - make the specified warning(s) into an error
-Wno-error=XXX - do not treat specified warning as error
where XXX would be the same tags as documented for --warn=XXX
disabled warnings would not cause errors, so to make sense
-Werror=XXX would imply --warn=XXX;
For the case cited, I could then say:
-Werror=missing-sconscript
in order to have my build fail, rather than have a missable message log
itself somewhere in a 50,000-line build log. Yes, they're that big in
the case of the CI builds :(
I am not wedded to any exact syntax, the gcc syntax is to illustrate.
framing before filing a github issue.
A call to an sconscript which is not found is a warning, not an error.
To me that sounds dangerous. In fact, the project I'm working on has
some problems due to this, though it's largely our fault (a non-core
build which will not be executed directly, rather handed off to another
buildystem which in the end calls scons again, but only after moving
pieces around to craft a custom setup. PLEASE don't ask, it's too painful).
On initial discussion on irc, there was some sentiment that turning this
case fatal might be a good idea, with developers who don't want it to be
fatal able to trap the exception and proceed; but as I've poked around
in the code, it's clearly intentional: there are test cases to make sure
the warning is issued as expected, and a command-line warning to turn
on/off the printing of a warning message for this - but not one to make
it an error.
So I'm happy to to file a bug on changing this behavior if people agree
that's the right approach, but that feels like it might be an "API
change" - at least a change in long-standing behavior.
So how about this as an alternative? Can we add a mechanism to
selectively or all-in treat warnings as errors? If so I'd propose a
concept similar to gcc, such that:
-Werror - treat all warnings as errors
-Werror=XXX - make the specified warning(s) into an error
-Wno-error=XXX - do not treat specified warning as error
where XXX would be the same tags as documented for --warn=XXX
disabled warnings would not cause errors, so to make sense
-Werror=XXX would imply --warn=XXX;
For the case cited, I could then say:
-Werror=missing-sconscript
in order to have my build fail, rather than have a missable message log
itself somewhere in a 50,000-line build log. Yes, they're that big in
the case of the CI builds :(
I am not wedded to any exact syntax, the gcc syntax is to illustrate.