[Scons-users] missing sconscripts, and warnings/errors

Bill Deegan bill at baddogconsulting.com
Tue Jul 17 11:16:41 EDT 2018


Mats,

I think a less general but appropriate solution for this particular issue
is to add a new argument to SConscript which allows the file to not be
there and otherwise issues an error rather than a warning.
With the default to be Error.

In the spirit of Make's include directive

https://www.gnu.org/software/make/manual/html_node/Include.html

You can have:
include somefile.mk. (which means include the file and error if not there)
or
-include somefile.mk (which means gnore a makefile which does not exist or
cannot be remade, with no error message)

Thoughts?
-Bill

On Tue, Jul 17, 2018 at 10:23 AM, Mats Wichmann <mats at wichmann.us> wrote:

>
> 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.
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20180717/d8f3ca10/attachment.html>


More information about the Scons-users mailing list