Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

["Alex Bennée" <alex.bennee@linaro.org>]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> On 5/26/2026 3:47 AM, Alex Bennée wrote:
>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>> 
>>> On 5/25/2026 11:43 AM, Alex Bennée wrote:
>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>
>>>>> On 5/25/2026 8:46 AM, Pierrick Bouvier wrote:
>>>>>> On 5/23/2026 1:56 AM, Alex Bennée wrote:
>>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>>
>>>>>>>> On 5/22/2026 12:02 PM, Alex Bennée wrote:
>>>>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>>>>
>>>>>>>>>> On 5/21/2026 6:17 AM, Alex Bennée wrote:
>>>>>>>>>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>>>>>>>>>> ensure they get built. This is especially important for MacOS which
>>>>>>>>>>> otherwise only builds the unsigned binaries on a normal "make all"
>>>>>>>>>>> run.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm not sure to see why it matters. tcg-tests don't make use of hvf, so
>>>>>>>>>> unsigned binaries are plenty for it.
>>>>>>>>>>
>>>>>>>>>> Which other binary is this building that is not built by default?
>>>>>>>>>>
>>>>>>>>>> In general, if something is not included in "all" target, let's make
>>>>>>>>>> sure it's included there (meson.build?) instead of adding a workaround
>>>>>>>>>> here. Not only tests benefit this, but anyone doing a build on a
>>>>>>>>>> platform that might have optional binaries not built by default.
>>>>>>>>>
>>>>>>>>> If you have a suggestion on how to make that work I'm all ears.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I would be happy to help, but I don't understand what the goal is. I
>>>>>>>> have three questions that should help to provide a suggestion.
>>>>>>>>
>>>>>>>> Which exact test command do you run?
>>>>>>>
>>>>>>> make check-tcg
>>>>>>>
>>>>>>>>
>>>>>>>> ```
>>>>>>>> Explicitly set the appropriate QEMU binary as a dependency so we can
>>>>>>>> ensure they get built.
>>>>>>>> ```
>>>>>>>> Aren't they built by all?
>>>>>>>
>>>>>>> Apparently not.
>>>>>>>
>>>>>>>> It seems to be a dependency, at least for check-tcg:
>>>>>>>> .ninja-goals.check-tcg = all test-plugins
>>>>>>>>
>>>>>>>> ```
>>>>>>>> This is especially important for MacOS which otherwise only builds the
>>>>>>>> unsigned binaries on a normal "make all" run.
>>>>>>>> ```
>>>>>>>> Why do you need signed binaries for testing on MacOS (hvf?)?
>>>>>>>
>>>>>>> In a previous iteration I made configure spit out the unsigned binaries
>>>>>>> to config-target.mak but the request was to fix the dependencies
>>>>>>> instead.
>>>>>>>
>>>>>>> It all works on Linux so I'm not sure why MacOS is being so weird
>>>>>>> because the meson emulators target mechanism should be the same.
>>>>>>>
>>>>>>
>>>>>> Just tried now, and it does not work on Linux neither (make check-tcg
>>>>>> does not build any target beyond tests). Maybe you forgot to clean your
>>>>>> folder?
>>>>>>
>>>>>
>>>>> The root issue is that tests/Makefile.include is included *after*
>>>>> evaluation of ninja-targets in main Makefile. Thus,
>>>>> .ninja-goals.check-tcg is ignored.
>>>>
>>>> So this replaces patch 1/16 - I think we have a circular dependency here.
>>>>
>>>
>>> Indeed, I didn't notice the duplication. While it solves things under
>>> Linux, it doesn't trigger any build on MacOS, which is what you observed
>>> also. I wonder if it's a gmake vs whatever-make difference.
>>>
>>> Another solution that seems ok on both platforms is to use (harmful)
>>> recursive make:
>>>
>>>  .PHONY: check-tcg
>>> -.ninja-goals.check-tcg = all test-plugins
>>> -check-tcg: $(RUN_TCG_TARGET_RULES)
>>> +check-tcg:
>>> + $(MAKE) all test-plugins
>>> + $(MAKE) $(RUN_TCG_TARGET_RULES)
>>>
>>>  .PHONY: clean-tcg
>>>  clean-tcg: $(CLEAN_TCG_TARGET_RULES)
>>>
>>> Or maybe just leave it as it is? Doc already mentions build should be
>>> done before running any test to avoid missing binaries.
>>> Hopefully we'll completely move tcg tests to meson one day, so there is
>>> no need to deal with make idiosyncrasy anymore.
>> 
>> The blocker for that to happen would be meson knowing about anything
>> else than the host compiler and singular cross compiler.
>>
>
> Meson indeed supports a single compiler + cross compiler at a time.
> However, you can directly generate cross binaries using a custom_target
> or a generator object. This way, meson would generate programs without
> having to know it's a C compiler. Since all files are single source,

That is an incorrect assumption - the softmmu binaries especially have a
multiple objects which are linked together.

> it's not a problem, since we don't need to declare them.
> Generators have the advantage of being less verbose (you declare only
> once how to use them) than custom target when used several times.
>
> https://mesonbuild.com/Reference-manual_functions_generator.html
> https://mesonbuild.com/Generating-sources.html#using-generator
>
> See a full working example below:
> ```
> $ cat meson.build
> project('cross_compile_tests', 'c')
>
> cc_aarch64 = generator(
>                find_program('aarch64-linux-gnu-gcc'),
>                arguments: ['@INPUT@', '-o', '@OUTPUT@', '@EXTRA_ARGS@'],
>                output: '@BASENAME@')
>
> tests = [
>   cc_aarch64.process('test.c'),
>   cc_aarch64.process('test2.c', extra_args: '-lpthread')
> ]
> # we need a target that actually uses tests
> executable('test_aarch64', 'empty_main.c', tests)
>
> $ mkdir -p build && cd build
> $ meson && ninja -v
> [1/4] /usr/bin/aarch64-linux-gnu-gcc ../test.c -o test_aarch64.p/test
> [2/4] /usr/bin/aarch64-linux-gnu-gcc ../test2.c -o test_aarch64.p/test2
> -lpthread
> [3/4] ccache cc -Itest_aarch64.p -I. -I.. -fdiagnostics-color=always
> -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O0 -g -MD -MQ
> test_aarch64.p/empty_main.c.o -MF test_aarch64.p/empty_main.c.o.d -o
> test_aarch64.p/empty_main.c.o -c ../empty_main.c
> [4/4] cc  -o test_aarch64 test_aarch64.p/empty_main.c.o -Wl,--as-needed
> -Wl,--no-undefined
> $ file test_aarch64.p/test*
> test_aarch64.p/test:  ELF 64-bit LSB pie executable, ARM aarch64,
> version 1 (SYSV), dynamically linked, interpreter
> /lib/ld-linux-aarch64.so.1,
> BuildID[sha1]=8162b8f045880c75118958ad46be78ed75bb708d, for GNU/Linux
> 3.7.0, not stripped
> test_aarch64.p/test2: ELF 64-bit LSB pie executable, ARM aarch64,
> version 1 (SYSV), dynamically linked, interpreter
> /lib/ld-linux-aarch64.so.1,
> BuildID[sha1]=eed48625e02cd436a2708f94e5dd9ce6d5c162a9, for GNU/Linux
> 3.7.0, not stripped
> ```
>
> We'll need to remove the mechanic to build cross compilers containers.
> In my experience, it's clunky anyway and fails when building several
> from scratch. Try it yourself after cleaning your docker/podman images.
> It's just better and simpler to expect user to install cross
> compilers.

That would loose a bunch of functionality and doesn't help users running
anything that isn't Debian.

> The only thing that prevented me to implement this before is that I
> didn't know if concerned maintainers would accept it, or just hold onto
> the precious handcrafted Makefiles, into which so much energy and time
> has been spent.

There is no desire to hold onto Makefiles, but I do want to keep the
same capabilities as the current system. The driver for containerising
the compilers was that setting up cross compilers is a barrier to
contributors who want to be able to add and build tests.

> If it's not the case, then we should definitely move into the direction
> of migrating all this to meson, and rely on meson tests infrastructure.
>
> Regards,
> Pierrick

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro