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

[Tom Rini]

On Thu, Aug 31, 2023 at 01:22:13PM -0600, Simon Glass wrote:
> 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?

Extend the list of files that we do keep today, so that at least more
cases could work, set aside the "everything else is an error" notion for
now.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230831/d066df3b/attachment.sig>