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

[Bill Deegan]

Thomas,

Indeed. For this item assuming a default of erroring for non-existant
sconscripts is the goal, then the Error would be toned down to deprecation
warning, then full error.

The question being, is there any reason not to target a default of
error'ing and a flag to allow just a warning?
(other than deprecation concerns)

Here's the formal SCons deprecation policy.
https://github.com/SCons/scons/wiki/DeprecationCycle

-Bill

On Tue, Jul 17, 2018 at 11:35 AM, Thomas Berg <merlin66b at gmail.com> wrote:

> 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
>>
>
> _______________________________________________
> 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/aa6f7019/attachment.html>