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

[Thomas Berg]

My main thought is to consider backwards compatibility. A use case that is
important to me is to check out and build old revisions of our codebase.
One thing I've liked with SCons is that I can have the most recent version
installed, and not have to downgrade to be able to build fairly old
revisions of our code.

Therefore, it should at least be possible to disable this error and make
the build pass without changing any code in the SConscripts, at least
initially.

One can make breaking changes to SCons of course, but in my opinion one
shouldn't do it lightly (just for minor cleanups with only slight
benefits), and one should follow normal deprecation policies so people have
time to prepare for breaking changes.



On Tue, Jul 17, 2018 at 5:16 PM Bill Deegan <bill at baddogconsulting.com>
wrote:

> 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
>>
>
> _______________________________________________
> 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/1c6a13b2/attachment-0001.html>