On Mon, Feb 6, 2023 at 12:55 AM Sebastian Huber < 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 > > 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. --joel > > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ > _______________________________________________ > 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
