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

[Tom Rini]

On Mon, Aug 28, 2023 at 11:54:55AM -0600, 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 think all of the complaints thus far have shown the problem with
trying to enforce an arbitrary limit here.

-- 
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/20230828/56b82f37/attachment.sig>