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.
Kinsey
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
