William, Any change which breaks compatibility will need to go in a major version change and not a minor or patch number release.
-Bill On Tue, Jun 2, 2015 at 3:59 PM, William Blevins <[email protected]> wrote: > Jason, > > If I understand this correctly. I have a similar issue in Parts. I found >> that it was that the scanner did not expand the path correctly via not >> calling subst() before it tried to access the variable. This caused >> failures in correctly finding libs and or header on first pass builds. It >> would also call possible rebuild on second pass or in some cases a false >> rebuild as SCons thought the path changed. >> > > This isn't (too my understanding) related to the patch in question. > > >> However I might have missed something in terms of this patch as I did not >> know the install builder called a scanner. ( you did mean the install.py >> tool.. or was this something else?) the install tools as I understand does >> not have a scanner mapped to it. > > > All builders call a scanner or at least try to find a scanner to call > (whether implicitly or explicitly). Sometimes this was simply handled as a > None case. In order to finish the patch, I need to make a choice (Case A > or Case B). Neither are 100% backwards compatible with previous behavior, > but both are reasonable I believe. > > 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
