On 4/5/25 07:27, Philippe Mathieu-Daudé wrote:
On 5/4/25 03:03, Pierrick Bouvier wrote:
On 4/4/25 14:53, Philippe Mathieu-Daudé wrote:
On 4/4/25 20:20, Pierrick Bouvier wrote:
On 4/3/25 16:57, Philippe Mathieu-Daudé wrote:
We would like to get rid of '-I target/$ARCH/' in the CPPFLAGS.
While this change is correct, this is not strictly needed.
With the current approach, using a set of common files per architecture,
we can rely on this include to be present, and it does not block from
having common files.
Indeed, I rebased this commit from my heterogeneous branch.
I'll keeping carrying / rebasing it for various months, trying to
remember to not keeping posting it.
Or alternatively I'll post it in a separate "cleanup series", not
mentioning single-binary or heterogeneous emulation.
My point was not "please post that later", but simply to say those
changes are not needed, now or in the future.
We can have a specific include path for various files without
compromising the single binary/heterogenenous, as long as we compile it
only once.
Incorrect, this is required for heterogenenous emulation.
There are probably two different topics here.
If by "this", you mean the current change (include explicit
target/X/cpu.h), then no, it's not required.
Changing include "cpu.h" to include "target/arm/cpu.h" has absolutely no
effect for the common files in hw/arm, as they are already compiled with
-I target/arm. It produces the exact same compilation unit.
I did the same change as you do here when working on hw/arm, and finally
understood it had no effect, so I reverted it, and simply let the
original include "cpu.h".
If you were talking about accessing arm/cpu.h features, then I still
don't see why it's needed. There is no reason any code out of hw/arm or
target/arm should access this. If I missed something, feel free to post
a concrete example of where it's needed.
In any case, if any hw code relies on cpu.h inclusion, it will not
compile when we make it common, because cpu.h won't be found.
At this time, and only at this time, then we'll extract the expected
interface, and expose it to common code. But before we meet the
situation, I don't think we should do any of those changes.
Pierrick
