<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 6, 2023 at 12:55 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 06.02.23 03:35, Chris Johns wrote:<br>
> On 4/2/2023 6:11 am, Sebastian Huber wrote:<br>
>> On 03.02.23 19:45, Kinsey Moore wrote:<br>
>>> This is my first stab at solving this duplicate install problem. I could<br>
>>> manually solve the problem by deduplicating the object includes and moving it<br>
>>> up to the BSP, but that is less intuitive since these drivers both depend on<br>
>>> the same code and the BSP doesn't depend on it directly.<br>
>><br>
>> Why don't you add the shared stuff to a objxilcommon.yml?<br>
>><br>
>> The approach in the wscript is a bit complex from my point of view.<br>
> <br>
> I am OK with adding this code or something similar. It is no more complex than<br>
> other places I have reviewed, eg `Item._init_link()`.<br>
> <br>
> The issue is currently not easy to see and may be present in other places<br>
> without us knowing. I am also fine with a spec file check that highlights a<br>
> clash to draw attention to a problem when the spec files are parsed. I feeling<br>
> we need something.<br>
<br>
If you install with<br>
<br>
./waf install -vv<br>
<br>
you see the duplicate install targets. See also<br>
<br>
<a href="https://gitlab.com/ita1024/waf/-/issues/2329#note_467849523" rel="noreferrer" target="_blank">https://gitlab.com/ita1024/waf/-/issues/2329#note_467849523</a><br>
<br>
Before we add double for loops we should first analyze the underlying <br>
problem. In this case it is a diamond shaped build dependency graph.<br>
<br>
spec/build/bsps/objnandpsu.yml:  uid: objxilinxsupport<br>
spec/build/bsps/objqspipsu.yml:  uid: objxilinxsupport<br>
spec/build/bsps/aarch64/xilinx-zynqmp/objjffs2qspinor.yml:  uid: <br>
../../objqspipsu<br>
spec/build/bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml:  uid: ../../objnandpsu<br>
<br>
In addition to the duplicate install targets you build also the objects <br>
of objxilinxsupport twice and add them to the library.<br>
<br>
I would simply move the links to grp_zu3eg:<br>
<br>
grp_zu3eg.yml:  uid: ../../objxilinxspport<br>
grp_zu3eg.yml:  uid: ../../objnandpsu<br>
grp_zu3eg.yml:  uid: ../../objqspipsu<br></blockquote><div><br></div><div>That's the solution in this case but wouldn't it be nice to detect it reliably and</div><div>address it when it shows up again.</div><div><br></div><div>--joel </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
embedded brains GmbH<br>
Herr Sebastian HUBER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 16<br>
fax:   +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>