On Friday, November 15, 2019 at 2:46:53 PM UTC+1, Baurzhan Ismagulov wrote:Hello Cedric,
Hello!
On Tue, Nov 12, 2019 at 11:20:15AM -0800, chomb...@gmail.com wrote:
> Is this patch series ready for merge or is there anything that needs fixing?
Looks good to me. I've applied it to ibr/next. I'll do some more checks and let
you know (the commid id will change). Please check #3, it failed for some
reason, I had to apply it manually.
Rebased locally (it did apply cleanly for me) - will anyway send v5
Regarding #1, it's an upstream feature. Do you know how Yocto deals with that?
E.g., does clean remove all of them? I found it useful once, when something was
broken and I could check the previous image. Also, I usually prefer not to
remove intermediate files to be able to debug stuff after the build. In this
case I agree that it's better to remove them.
I can check what upstream does but to answer the other question, clean unfortunately leaves them behind
WICTMP is created with mktemp -d so I wonder if we would have to store it somewhere if we wanted to keep files in the buildchroot
but delete them when we run do_clean
should we introduce WIC_DEBUG?= "0" and keep them if it was set to "1"?
Regarding #5, this is what many new users complain about: The configuration is
scattered through many files, it's difficult even to identify which variables
are available. MACHINE-centric tools with a single config file are much easier
to learn in this regard. Documenting stuff would be one option. But providing
few self-explaining locations with all variables is also important. Maybe we
could introduce meta/conf/arch/machine hierarchy and provide variables like
KERNEL_FILE there, at the cost of some repetition.
that sounds like a good idea but do we want to expand the scope of this patch series?
It would be nice to fix mips builds with our current design.
As an aside, do we have a central TODO list where we can record things we really want to
get done before we release something like 1.0? I recall seeing e-mails from different people
with own lists. Should we have it in the repo so it's easy to find?
With kind regards,
Baurzhan.