I build a number of different images where the tune parameters remain identical but we change MACHINE to make small changes in the target file system, the other change we typically make per MACHINE is to change the kernel config and device tree which results in a different kernel build. Since the kernel headers are part of the SDK that we create this means that we end up with one SDK per MACHINE. For the products I maintain this is a significant number of SDKs! What I'd like to do is produce one SDK per architecture but with all the variant kernel headers available in that SDK. To do this I've thought about only having a single MACHINE definition and then creating per-board kernel recipes and adding them all to the image. Taking this approach would just create problems in image creation since the differentiation for per MACHINE package changes and different target image creation would have been lost and I'd have to hack together some very product specific image creation and customisation step to re-introduce functionality currently provided by changing MACHINE. Is this something worth supporting generically rather than hacking something horribly specific to the use case above?
We'll think about the approach which at the moment we don't have a solid plan yet.
Is this the 'multilib' issue? What's the status for now?
Once multiconfig interdependencies work, this should be implementable.
We now have multiconfig available. I suspect there are two elements to this request. One would be to teach the SDK code how to combine multiple SDK toolchains together into one SDK. The best high level start would be a mixec architecture SDK where there were say ARM and x86 targets supported. The SDKs would already not overlap for this so this should be comparatively simple. We do something conceptually related for multilib already. The second step is harder and more related to this bug which is to have a sysroot per machine in the SDK, perhaps with common elements between the sysroots hardlinked to each other for efficiency. This would allow machine specific variances between the different SDK machines. I suspect machine specific SDK sysroots may be something users have to opt into and that right now today we have target_arch specific sysroots which is what makes this machine specific step harder.
Would it make sense to split the bug into two instead?
(In reply to comment #4) > We now have multiconfig available. I suspect there are two elements to this > request. One would be to teach the SDK code how to combine multiple SDK > toolchains together into one SDK. The best high level start would be a mixec > architecture SDK where there were say ARM and x86 targets supported. The > SDKs would already not overlap for this so this should be comparatively > simple. We do something conceptually related for multilib already. > > The second step is harder and more related to this bug which is to have a > sysroot per machine in the SDK, perhaps with common elements between the > sysroots hardlinked to each other for efficiency. This would allow machine > specific variances between the different SDK machines. > > I suspect machine specific SDK sysroots may be something users have to opt > into and that right now today we have target_arch specific sysroots which is > what makes this machine specific step harder. Conceptually I think the difference lies in "when" we merge the two of them together: In both cases, we would create a dependency from one mc to the other mc for it to build the packages needed for each SDK. - This is not as simple because TOOLCHAIN_HOST_TASK contains packages with MACHINE on it, so the cooker would complain since it can't provide a package that doesn't exist for that build, this should be fixable by adding the corresponding mc to packages on TOOLCHAIN_HOST_TASK or something similar, I believe this is doable. In the first case, we would build both the SDKs independently up to the installation stage, where we install the required built packages, we "simply" ask it to install the packages built for both SDKs. In the second case, we actually perform a proper merge, on which files are shared amongst different toolchains. But, on both cases, I believe the main problem is the same, each multiconfig build isn't aware of the other, each taskdata object only contains packages for a specific configuration. To put it in other words: The build itself knows its building several configurations, but each mc-build doesn't know about each other, or what each other is building / has built. This works fine for multiconfig dependencies because they are solved before building and the cooker (that has access to all taskdata objects) makes sure that they can be provided by the other mc-build, but in this case, it would have to be during the build. For example if we're building an SDK that contains both x86 and ARM variants even in the first case it wouldn't work: 1.: Packages will be generated for both on $TMPDIR-MCx86/deploy/$IMAGE_PKGTYPE and $TMPDIR-MCARM/deploy/$IMAGE_PKGTYPE respectively (They would probably have to use the same IMAGE_PKGTYPE but that's a different issue). 2: During installation, the manifests would be parsed and the resulting packages files (rpm,deb,ipk) will be hardlinked into the sysroot, where they would later be used to be installed. - This wouldn't work because the x86 build isnt aware of where the manifests for the ARM build are located, and it does not have access to $TMPDIR-MCARM. Correct me if I'm wrong, but I believe the multilib class extension doesn't have this issue because the packages are within the same build, I get that we could somehow "extend" the packages to differentiate them depending on which mc they come from but the above problem remains the same. We would need to find a way to share information between the builds (if thats ok), or build them separately and merge them both from a layer above where we have access to all the taskdata objects (which I think it seems wrong)