[PATCH] wscript: Deduplicate installed files
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
>> > 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
>> Before we add double for loops we should first analyze the
>> 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:
>> spec/build/bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml: uid:
>> In addition to the duplicate install targets you build also the
>> 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:
> 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.
More information about the devel