William, On Sun, Apr 3, 2016 at 5:51 PM, William Blevins <[email protected]> wrote:
> Does the ability to disable the check at a global and/or per call level > satisfy their requirements? > Requirements is probably not the best word. The question is will it break their build? It sounds like not, it'll just be a warning. Second question would be is there a valid/logical reason to have a None value returned/stored as a Node? Seems unlikely.. an empty list would be a better value for such. Anyone else have thoughts? -Bill > > V/R, > William > > On Mon, Apr 4, 2016 at 1:34 AM, Bill Deegan <[email protected]> > wrote: > >> William, >> >> I've seen users with source and/or target as None. >> Usually they want to force an item to always build, or they don't >> understand that they are actually producing a file (or files) worthy of >> being the "target", or that they should/can create a token file for this >> purpose. >> >> So I guess your suggested change (which I think would be helpful for >> many) would affect them. >> >> -Bill >> >> On Sun, Apr 3, 2016 at 11:37 AM, William Blevins <[email protected]> >> wrote: >> >>> Krew, >>> >>> It seems that the issue of having dependencies of NoneType.None is >>> rather common and can be difficult to track down from personal experience. >>> I think we should consider adding code that throws an exception if >>> NoneType.None is added via env operations like Append, AppendUnique, >>> Prepend, etc. >>> >>> For backwards compatibility reasons were someone wants NoneType.None, we >>> could have both a global check disable and/or an optional parameter to >>> disable checks. >>> >>> Any thoughts? >>> >>> V/R, >>> William >>> >>> _______________________________________________ >>> Scons-dev mailing list >>> [email protected] >>> https://pairlist2.pair.net/mailman/listinfo/scons-dev >>> >>> >> >> _______________________________________________ >> Scons-dev mailing list >> [email protected] >> https://pairlist2.pair.net/mailman/listinfo/scons-dev >> >> > > _______________________________________________ > Scons-dev mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
