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

[Oliver Koch]

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


--
Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
www.avast.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20250403/c24a0718/attachment.htm>