[PATCH 0/6] Attempt to enforce standard extensions for build output

[Simon Glass]

Hi Tom,

On Thu, 31 Aug 2023 at 13:07, Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, Aug 31, 2023 at 01:01:59PM -0600, Simon Glass wrote:
> > Hi Alper,
> >
> > On Thu, 31 Aug 2023 at 04:20, Alper Nebi Yasak <alpernebiyasak at gmail.com> wrote:
> > >
> > > On 2023-08-28 20:54 +03:00, Simon Glass wrote:
> > > > Hi Alper,
> > > >
> > > > On Sun, 27 Aug 2023 at 13:17, Alper Nebi Yasak <alpernebiyasak at gmail.com> wrote:
> > > >>
> > > >> On 2023-08-24 06:02 +03:00, Simon Glass wrote:
> > > >>> In this early stage of using binman to produce output files, we are mostly
> > > >>> seeing people using common extensions such as '.bin' and '.rom'
> > > >>>
> > > >>> But unusual extensions appear in some places.
> > > >>>
> > > >>> We would like 'buildman -k' to keep the build outputs, but this is hard if
> > > >>> there is no consistency as to the extension used.
> > > >>>
> > > >>> This series adjusts binman to enforce just 4 extensions for output images:
> > > >>>
> > > >>>    .bin
> > > >>>    .rom
> > > >>>    .itb
> > > >>>    .img
> > > >>>
> > > >>> Other extensions will produce an error. With this rule observed, buildman
> > > >>> can keep the required files.
> > > >>
> > > >> I dislike this limitation. We know what files we will generate, they are
> > > >> listed in binman dtb, so we can add something like `binman build --ls`
> > > >> to print their names/paths for buildman to preserve them.
> > > >
> > > > Yes, it would be good to have that...
> > > >
> > > > But why do you dislike the limitation? Do you think extensions provide
> > > > useful information? I suppose one problem is that *.bin might pick up
> > > > private blobs that happen to be in the source directory?
> > >
> > > I guess my strongest argument is that people already/will have workflows
> > > that depend on certain filenames or extensions, and shouldn't have to
> > > modify binman code (consider that people may be using the PyPI wheels)
> > > to accommodate those when we are already putting the name in the dtb.
> > >
> > > I do want some standardization to the U-Boot build outputs though, but
> > > more like a global binman.dts with like u-boot.rom, u-boot-sdmmc.img
> > > images with well-defined TPL, SPL, U-Boot sections that arch-dtsi files
> > > can fill in.
> > >
> > > >> Regarding the output directory suggestion, I think the binman outputs
> > > >> (not temporary/intermediate files) should be in the same directory as
> > > >> make outputs
> > > >
> > > > Agreed
> > > >
> > > >> , and the Makefile should default to O=build to achieve the
> > > >> "output dir". I'm not sure if that's going to happen.
> > > >
> > > > I would quite like the 'non-output' file (i.e. things that are not a
> > > > binman image) to appear in a 'binman-work' subdir of the output dir.
> > > > What do you think?
> > >
> > > I'd prefer them to go in a tempfile.TemporaryDirectory() and discarded
> > > at the end of a binman run, and a "--tmpdir <path>" option to use a
> > > given directory instead and preserve things for debugging.
> >
> > Actually, that was the original purpose of the output directory in the
> > u_boot_pylib.tools module. But with all the files binman creates, that
> > has been lost. I think we should restore that purpose (with an output
> > dir as a temp dir) and then I think what you have written here will
> > work.
>
> Just please note the rest of the feedback that's been given to this
> series too.

Yes. It is a bit hard to know what to do. I suppose we need binman to
publish a list of the image files it writes, so buildman can use that
to save them. Or we could just add some more special cases to the rule
in buildman?

Regards,
Simon