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

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 3283 bytes --]

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@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@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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]