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.
--
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
