[PATCH v2 2/2] kbuild: Use relative paths in generated .incbin directives

[Rasmus Villemoes]

On Fri, Mar 27 2026, Simon Glass <sjg at chromium.org> wrote:

> Hi Rasmus,
>
> On Fri, 27 Mar 2026 at 04:27, Rasmus Villemoes <ravi at prevas.dk> wrote:
>>
>> On Fri, Mar 27 2026, Rasmus Villemoes <ravi at prevas.dk> wrote:
>>
>> > On Thu, Mar 26 2026, Simon Glass <sjg at chromium.org> wrote:
>> >
>> >> The generated .S files for fonts and splash screens use .incbin with the
>> >> full prerequisite path. When building with O= this bakes an absolute
>> >> path into the .S file. If the build directory is later used on a
>> >> different machine (e.g. in a container), the assembler cannot find the
>> >> source file.
>> >
>> > I must be missing something, because I can't see how this can be a
>> > problem, while all the other absolute paths to the source dir that go
>> > into files generated in the build directory is not. For example, there's
>> > a top-level "source -> /path/to/u-boot" symlink created, and as far as I
>> > can tell, all the .foo.o.cmd files end up full of such references as
>> > well, e.g. $BUILD/lib/.vsprintf.o.cmd contains
>> >
>> > source_lib/vsprintf.o := /path/to/u-boot/lib/vsprintf.c
>
>>
>> OK, I can sort-of reproduce, though I don't know if what I did is
>> representable for your use case. No containers involved, just moved the
>> source directory.
>>
>>   # original source dir
>>   $ cd /tmp/u-boot
>>   $ make O=/tmp/build sandbox_defconfig
>>   $ make O=/tmp/build -j7
>>   $ cd /tmp ; mv u-boot u-boot-new ; cd u-boot-new
>>   $ make O=/tmp/build -j7
>>
>> This breaks as you describe, but most files simply get rebuilt due to
>> their .cmd files containing stale references to /tmp/u-boot/. Which
>> suggests that the bug is really the lack of a .S.cmd file describing how
>> the .S file was created in the first place.
>>
>> This seems to be a better fix, which also causes the .S files to be
>> generated anew if one does some actual change to the rule:
>>
>> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
>> index 7386353e0cc..b2441080e7e 100644
>> --- a/scripts/Makefile.lib
>> +++ b/scripts/Makefile.lib
>> @@ -526,8 +526,8 @@ cmd_S_ttf=                                          \
>>         echo '.balign 16';                              \
>>  ) > $@
>>
>> -$(obj)/%.S: $(src)/%.ttf
>> -       $(call cmd,S_ttf)
>> +$(obj)/%.S: $(src)/%.ttf FORCE
>> +       $(call if_changed,S_ttf)
>>
>>  # Splash logos
>>  # ---------------------------------------------------------------------------
>> @@ -547,8 +547,8 @@ cmd_S_splash=                                               \
>>         echo '.balign 16';                              \
>>  ) > $@
>>
>> -$(obj)/%.S: $(src)/%.bmp
>> -       $(call cmd,S_splash)
>> +$(obj)/%.S: $(src)/%.bmp FORCE
>> +       $(call if_changed,S_splash)
>>
>>  # EFI applications
>>  # A Makefile target *.efi is built as EFI application.
>>
>> See e.g. kernel commit a7f9241909 which did essentially the same change
>> to the .dtb -> .S rule back in 2018.
>>
>> It still makes sense to put these rules in a u-boot specific makefile,
>> but this should avoid the need for each font .o file to need those
>> AFLAGS changes.
>
> Sure, but it causes the font/logo .S files to be rebuilt on every make
> invocation. How did you test this?

I didn't really test it beyond what I wrote, and I saw that the .cmd
file got rewritten and the whole second build succeeded. I did not think
to run the build twice from the same, unmoved, source repo.

> It would be nice to use if_changed though. It needs the .cmd file to
> be loaded via -include, which only happens for files in the targets
> variable. The generated .S files are never added to targets, so cmd_$@
> is always empty and if_changed always rebuilds.

Ah, yes, I did look at the logic for which .cmd files got included, but
yes, I didn't really think about whether the new ones would be or think
to test whether they were.

> The kernel commit you referenced (a7f9241909) works for DTB because
> .dtb.o has a compound suffix with a matching intermediate_targets
> entry. We could follow the same convention, renaming to .ttf.o/.bmp.o
> and adding:
>
> targets += $(call intermediate_targets, .ttf.o, .ttf.S) \
>            $(call intermediate_targets, .bmp.o, .bmp.S)
>
> The pattern stem stays the same, so symbol names are unaffected. What
> do you think?

Yes, that definitely seems to be the right approach, because it follows
the existing pattern for .dtb -> .dtb.S -> .dtb.o and similar.

Rasmus