Hi Alex, > On 26 Jun 2026, at 15:17, Alexander Kanavin <[email protected]> wrote: > > On Fri, 26 Jun 2026 at 09:39, Luca Fancellu <[email protected]> wrote: > >> I agree that having no in-tree consumer makes the patch weaker. One option I >> can add is a small meta-selftest consumer recipe that uses CMake >> find_package(MLIR CONFIG), links against the exported MLIR targets, and >> builds >> a tiny program using the TOSA dialect. That would not make MLIR part of any >> default image, but it would give oe-core coverage that the recipe exports a >> usable MLIR SDK/native integration and that the TOSA dialect APIs are >> available. >> >> If the preference is still that new recipes must have a production oe-core >> consumer rather than a selftest consumer, then I will drop this. > > Thanks, that all makes sense, and since oe-core adopted clang, it > should be providing all parts of it. Oe-core does not need to have a > 'production' consumer, and a synthetic test is fine, so at least it's > possible to know it's not completely broken. You need to extend the > commit message with this information, so it's recorded in git history. > > The one part that is missing and that I would like to see is a > 'production' usage of this in some other public layer. Is that being > developed somewhere? Presumably you're going to use this recipe for > 'real work', can you show it? The more usage you can show, the > stronger the case.
Thanks, that makes sense. For v2 I will extend the commit message with the MLIR/TOSA background and the oe-core rationale: MLIR is part of llvm-project, its consumers are version-coupled to LLVM/MLIR CMake exports, and carrying it in oe-core avoids downstream layers having to build or package a private LLVM/MLIR copy that can drift from oe-core's LLVM. I will also add a small selftest consumer recipe which uses find_package(MLIR CONFIG), links against the exported MLIR targets, and builds a tiny program using the TOSA dialect. That should give oe-core coverage that the recipe is usable without making MLIR part of any default build. On the production usage: I cannot point to a public OpenEmbedded/Yocto layer today. The concrete use case that triggered this work is not public yet, and I am not aware of another public layer consuming LLVM MLIR at the moment, so I do not want to overstate that part. I still think oe-core is the right place for this because it is an optional, standalone recipe for a component from the same llvm-project source tree that oe-core already provides. If the lack of a public production consumer makes it premature, I can hold the patch back until such a consumer is available. Otherwise I will send a v2 with the expanded commit message and selftest coverage. Cheers, Luca
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#239640): https://lists.openembedded.org/g/openembedded-core/message/239640 Mute This Topic: https://lists.openembedded.org/mt/119973309/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
