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. -- Tom
signature.asc
Description: PGP signature
