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 <tr...@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 <alpernebiya...@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 > > > > > <alpernebiya...@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
signature.asc
Description: PGP signature
