My take is that the scanner changes should improve the ability for the scanner to find files, anything short of that is a breaking backward compatibility. Any change that fixes the ability to find files where before it did not find them ( and it should have) if the correct direction. Test cases that fail because the scanner is finding files better, when before it did not find then and failed ( ie the test expects a failure) is not a regression. I believe this would say the B should not be supported as it seems to be based on the test failing to pass because the scanner failed to find files. When we do this fix and it find files, it works correctly ( ie passes) which I would argue is not a bad thing.
What I was stating below was that the main reason scanner failed for me was because bad ordering with subst() caused the scanner to fail ( recusive or not) However that is technically a different issue from this improvement. I thought might be related, but it is not for the test cases in question. My bad .. Given what I understand I agree with your suggestion to continue support A case and drop B support. One question … Case A: is this correct? We have A.h -> B.h The copy action for A.h is to copy as a.h.l The copy action for B.h is to copy as b.h.l There is a scanner for *.h There is no scanner for *.l ?? (I don’t think that matters for this case as there no actions with *.h.l files as source files to some other target) Actions chain should be like. 1) Scons see A.h depends on B.h so it installs b.h as b.h.l, then it installs A.h as a.h.l 2) On rebuild everything is up to date 3) On modify of b.h scons does 1) set of actions. Correct? I think that is efficient and correct. I should be able to say this in Parts for example as get the same logic as the scanner are implicit…. … env.CCopyAs([‘a.h.l’,’b.h.l’’],[‘a.h’,’b.h’]) … Since the scanner for the .h files will be run by the CCopy builder in Parts for a given file, even though I don’t have a scanner for the source or target files in the builder directly. I should be able add such a test to verify this behavior with the implicit scanner on a random builder. Is this correct? Thanks Jason From: Scons-dev [mailto:[email protected]] On Behalf Of William Blevins Sent: Tuesday, June 2, 2015 6:00 PM To: SCons developer list Subject: Re: [Scons-dev] SCons cross-language support 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
