[PATCH] wscript: Deduplicate installed files

Kinsey Moore wkm042 at oarcorp.com
Mon Feb 6 20:03:33 UTC 2023


On 2/6/2023 8:44 AM, Sebastian Huber wrote:
> On 06.02.23 15:30, Joel Sherrill wrote:
>> On Mon, Feb 6, 2023 at 12:55 AM Sebastian Huber 
>> <sebastian.huber at embedded-brains.de 
>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>>     On 06.02.23 03:35, Chris Johns wrote:
>>      > On 4/2/2023 6:11 am, Sebastian Huber wrote:
>>      >> On 03.02.23 19:45, Kinsey Moore wrote:
>>      >>> This is my first stab at solving this duplicate install
>>     problem. I could
>>      >>> manually solve the problem by deduplicating the object includes
>>     and moving it
>>      >>> up to the BSP, but that is less intuitive since these drivers
>>     both depend on
>>      >>> the same code and the BSP doesn't depend on it directly.
>>      >>
>>      >> Why don't you add the shared stuff to a objxilcommon.yml?
>>      >>
>>      >> The approach in the wscript is a bit complex from my point of 
>> view.
>>      >
>>      > I am OK with adding this code or something similar. It is no more
>>     complex than
>>      > other places I have reviewed, eg `Item._init_link()`.
>>      >
>>      > The issue is currently not easy to see and may be present in
>>     other places
>>      > without us knowing. I am also fine with a spec file check that
>>     highlights a
>>      > clash to draw attention to a problem when the spec files are
>>     parsed. I feeling
>>      > we need something.
>>
>>     If you install with
>>
>>     ./waf install -vv
>>
>>     you see the duplicate install targets. See also
>>
>>     https://gitlab.com/ita1024/waf/-/issues/2329#note_467849523
>> <https://gitlab.com/ita1024/waf/-/issues/2329#note_467849523>
>>
>>     Before we add double for loops we should first analyze the 
>> underlying
>>     problem. In this case it is a diamond shaped build dependency graph.
>>
>>     spec/build/bsps/objnandpsu.yml:  uid: objxilinxsupport
>>     spec/build/bsps/objqspipsu.yml:  uid: objxilinxsupport
>>     spec/build/bsps/aarch64/xilinx-zynqmp/objjffs2qspinor.yml: uid:
>>     ../../objqspipsu
>>     spec/build/bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml:  uid:
>>     ../../objnandpsu
>>
>>     In addition to the duplicate install targets you build also the 
>> objects
>>     of objxilinxsupport twice and add them to the library.
>>
>>     I would simply move the links to grp_zu3eg:
>>
>>     grp_zu3eg.yml:  uid: ../../objxilinxspport
>>     grp_zu3eg.yml:  uid: ../../objnandpsu
>>     grp_zu3eg.yml:  uid: ../../objqspipsu
>>
>>
>> That's the solution in this case but wouldn't it be nice to detect it 
>> reliably and
>> address it when it shows up again.
>
> You can detect the issue with by calling ./waf -vv install. This is 
> what the maintainer of waf recommends:
>
> https://gitlab.com/ita1024/waf/-/issues/2329#note_467849523
>
> I would rather try to get these warnings by default from waf instead 
> of tinkering with special case solutions above waf.
>
> The patch doesn't address the issue with the multiple object files in 
> the library.
>
It sounds like we consider this an error which is fine by me. I'll drop 
this patch and deduplicate the objects manually.

I would like to find a way to make this an actual error which will stop 
the build instead of hiding a warning behind the -v flag. I'll see what 
I can do along these lines.


Kinsey



More information about the devel mailing list