[PATCH] wscript: Deduplicate installed files

[Gedare Bloom]

On Mon, Feb 6, 2023 at 1:03 PM Kinsey Moore <wkm042 at oarcorp.com> wrote:
>
> 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.
>
The linked Issue suggests that it occasionally comes up as a false
positive, which is why tnagy didn't make it an error.

>
> Kinsey
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel