[Scons-dev] SCons cross-language support

William Blevins wblevins001 at gmail.com
Wed Jun 3 13:08:49 EDT 2015


To be clear, Case A and Case B are related.

I can resolve one issue but not both, so its really a multiple choice
question.
On Wed, Jun 3, 2015 at 9:47 AM, Kenny, Jason L <jason.l.kenny at intel.com>
wrote:

>  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.
>

Correct.  On step three, both B.h and A.h will be reinstalled due to the
dependency chain even though A.h has not changed.  It is correct, but not
efficient.  I believe to fix the efficiency, Install (and copy) should
behave more like rsync than a plain copy.  The install of A.h did not
happen on step 3 before the scanner improvements.

I can fix the inefficiency by removing support for Case B.  In my opinion
Case B shouldn't be supported anyway, since I do not think that Use Case
makes sense for the Install builder.  I could possibly see using Copy for
this Use Case but not Install.  The issue with some of the SCons tests are
that the tests define how the program behaved previously, but they do not
define how the program was intended to behave.  I'm not sure whether Case B
was supported intentionally or it just happened to work.


>
>
> 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:scons-dev-bounces at scons.org] *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
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20150603/a5f99cf3/attachment-0001.html>


More information about the Scons-dev mailing list