[Scons-users] Fwd: Dependency tree for test framework

[Bill Deegan]

BTW in SCons compilers and linkers are not considered immutable and are
usually content bashed and in the dependency tree.

So something like this should work:

DefaultEnvironment(tools=[])
env=Environment(tools=[])
env.Command(['aNew/b.out','aNew/b.log],['a.ini','b.dat'],'./aNew.exe')
env.Command(['aOld/b.out','aOld/b.log],['a.ini','b.dat'],'./aOld.exe')
env.Command(['aNew/b.out.tmp','aOld/b.out.tmp'],['aNew/b.out','aOld/b.out'],'./PreProcess.py')
env.Command('b.log.diff',['aNew/b.log','aOld/b.log'],'./LogDiff.exe')
env.Command('b.out.diff',['aNew/b.out.tmp','aOld/b.out.tmp'],'./OutDiff.py')


This assumes you don't want SCons to also build aNew.exe, aOld.exe,
LogDiff.exe.
If you do, then you'd remove tools=[] from Environment, and add some
env.Program()'s above.
-Bill



On Thu, Apr 3, 2025 at 2:26 PM Bill Deegan <bill at baddogconsulting.com>
wrote:

> Ahh so the arrows are the opposite of how one normally diagrams a build
> DAG..
>
> So PreProcess.py doesn't depend on a{New,Old}/b.out, it just read them, in
> reality a{New,Old}/b.out.tmp depends on PreProcess.py and respectively
> a{New,Old}b.out ?
>
> -Bill
>
> On Thu, Apr 3, 2025 at 2:06 PM Oliver Koch via Scons-users <
> scons-users at scons.org> wrote:
>
>> Dear all,
>>
>> I have seen that my mail was received and I also got some answers. Thank
>> you for that! Appreciated.
>>
>> However, I do not know, how to answer, so I write another mail and hope
>> that the subject will assign it to my thread.
>>
>> @Mats Wichmann:
>> Thank you for the hints to the two chapters.
>> I will look into it.
>>
>> @Keith Prussing:
>> Thank you for the hints to ToolsForFools.
>> I will look into it.
>>
>> @Bill Deegan:
>>
>> > wow that's about the most complicated way to share your dependencies I've
>> > seen so far..
>>
>> I am sorry. I thought the tree is clearer than a long verbal explanation.
>>
>> > I see an arc from aOld\b.out.tmp -> aOld\b.out which goes around
>> > PreProcess.py (same for aNew\b.out.tmp).
>> > How does b.out "use" the .tmp file directly?
>> > Or is that a mistake/error in your representation?
>>
>> Good point, but no, it is not a "mistake" (see below: 3 types of arrows).
>>
>> PreProcess.py reads aNew\b.out and writes aNew\b.out.tmp.
>>
>> If either PreProcess.py changes (e.g. because I fix a bug in the Python
>> script) or the input file aNew\b.out changes aNew\b.out.tmp must be
>> re-created. SCons should recognize this a re-create aNew\b.out.tmp
>>
>> The arrows should be read as "depends on" in one or the other way.
>> This is maybe, what causes confusion. I see 3 types of dependencies:
>> 1.) "reads" (from app to input file)
>>     aNew.exe reads a.ini
>>     aNew.exe reads b.dat
>>     PreProcess.py reads aNew\b.out
>>     and so on
>> 2.) "is created by" (from output file to app)
>>     aNew\b.out is created by aNew.exe
>>     aNew\b.out.tmp is created by PreProcess.py
>>     b.log.diff is created by LogDiff.exe
>>     and so on
>> 3.) "(logically) depends on" (from input to output file)
>>     aNew\b.out.tmp depends on aNew\b.out
>>     aOld\b.out.tmp depends on aOld\b.out
>>     (I skipped other arrows, e.g. from aNew\b.out to b.dat, for clarity.
>>     For the above two it was necessary to avoid the ambiguity that
>>     aNew\b.out.tmp depends only on aNew\b.out and
>>     aOld\b.out.tmp depends only on aOld\b.out.)
>>
>> > Also question how a.ini and b.dat can accept outputs from both aNew.exe and
>> > aOld.exe?
>> See above. Arrows show dependency (I guess this is UML compliant.).
>> The data flow goes in the oppsosite direction.
>>
>> PreProcess.py, LogDiff.exe, and OutDiff.py will not change very often, but I will not exclude it.
>> aNew.exe will change, since this is the app I am developing.
>> aOld.exe is the old app, so it should usually not change.
>>
>> So, all boxes should be regarded as "mutable".
>>
>> Usually, in a normal build system, the compiler and linker are regarded
>> as immutable. My situation is comparable to the scenario that I am
>> developing the compiler and linker (.exe/.py) and I want to check, whether the
>> build targets (.diff) are still the same, although the source files (.dat) or config (.ini) have not
>> changed.
>>
>> Kind regards,
>>
>> Oliver
>>
>> Am 29.03.2025 um 06:30 schrieb Oliver Koch:
>>
>> Dear Scons developers and users,
>>
>> I would like to set up a rather complex test framework to compare the
>> changes between different versions (old vs. new) of an executable.
>> The workflow also includes different steps (tools) to process resp.
>> compare the output files.
>>
>> See the attached HTML file (resp. the according Markdown file).
>> Any green box should be regarded as an independent component the can be
>> changed by me. Any white box is a dependent file that is generated from the
>> independents.
>>
>> The task is to create a dependency tree in SCons that re-generates the
>> (necessary) final output files (b.out.diff resp.b.log.diff), if any of the
>> dependent green boxes have been changed.
>>
>> I am struggeling with your documentation to conclude, how a SCons script
>> should look like for the above purpose, since I am not using any classical
>> compiler or linker in this workflow.
>> Could you indicate me, how the shown dependency tree must be implemented
>> with a SCons script?
>> (And maybe explain a little bit why?)
>>
>> Regards,
>>
>> Oliver
>>
>>
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>> Virenfrei.www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>> <#m_-6009214567214357308_m_-178949517691114710_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> _______________________________________________
>> 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/20250403/55577045/attachment.htm>