On Mon, Feb 6, 2023 at 1:03 PM Kinsey Moore <wkm...@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.hu...@embedded-brains.de > >> <mailto:sebastian.hu...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
