> 18 jan. 2019 kl. 15:40 skrev Richard Purdie > <richard.pur...@linuxfoundation.org>: > > On Fri, 2019-01-18 at 15:16 +0100, Ulf Samuelsson wrote: >>> 18 jan. 2019 kl. 12:29 skrev Richard Purdie < >>> richard.pur...@linuxfoundation.org>: >>> >>>> On Fri, 2019-01-18 at 05:30 +0100, Ulf Samuelsson wrote: >>>> So if KNOWN_TASKS is defined in a configuration file in oe-core, >>>> it >>>> would be OK? >>>> It needs to be extended to check for KNOWN_TASKS == None of >>>> course. >>> >>> No, this is too fragile. We then have to maintain two different >>> lists >>> of tasks. If we did that we may as well just remove the generic >>> tasks >>> mechanism and hardcode the tasks list in the metadata. >>> >> Why do we need two lists? > > If we change one of these "generic" tasks, we then need to remember to > also update KNOWN_TASKS. The same information is being encoded in two > places. > > Maintaining the same information in two different places means one of > those places inevitably ends up out of date.
We could insert a check if the KNOWN_TASKS is valid in a verification test. When building core-image-minimal, the task order within core-image-minimal is analyzed, (dependencies on all other recipes is filtered away). Then you find out if there are tasks added, missing, and/or in the wrong order. Best Regards, Ulf Samuelsson > >> We need to know in what order the generic tasks are executed, that is >> all. >> >> Then we need to see if an addtask is violating that order. >> If the ”after” or ”before” is not a generic task, the check cannot >> catch that. >> >> If the user decides to not use the generic tasks, and create new ones >> with the same name, as the generic tasks, but rearranges the order, >> there will be a problem, but I do not see any other problems. >> >> Please enlighten me! > > This has the problem that the code will find some subset of the bugs > but not all of them. We'll then get users reporting that the tests > failed and asking for the checks to be improved. > > So no, we are not doing this, sorry. > > Cheers, > > Richard > > -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
