On 23/1/2024 5:27 am, Sebastian Huber wrote: > ----- Am 22. Jan 2024 um 0:22 schrieb Chris Johns chr...@rtems.org: > >> On 17/1/2024 11:39 pm, Sebastian Huber wrote: >>> Hello, >>> >>> attached is a proof of concept. Using a ./waf bootimages command didn't work >>> since you don't have a build context in this case. I added a new option: >>> >>> # If this option is enabled, then boot images for the test programs >>> # are built. >>> BUILD_BOOT_IMAGES = False >>> >>> If this option is enabled, then a BSP-specific method is used to build a >>> boot >>> image. This method is optional. BSPs can provide it through a new build item >>> with type "mkimage", see the powerpc/qoriq example of the attached patches. >> >> Thanks for looking into this. I have not reviewed the patches because they >> are >> attached which means downloading, opening etc and they are stripped from the >> list archives so not visible there. I am happy to review changes once I >> understand the requirements. > > The old build system had a bsp-post-link hook, so this is not really > something new
Yes and that was a weakness in that build system so I would prefer we do not repeat the same mistake. The hook was exported as a make target and if you did not use Makefile.inc you had no access to the hook and any of the information and details embedded in it. This became apparent when the pkconfig (.pc) was first introduced. There was no means to extract the logic as the hook was specific to make with variables, defines and more. We can attempt to capture all the detail in an interface in the waf build system but how would that be exported in a way that lets a user with a cmake build system get that data and then be able to use it? This is the challenge. >> Is there a ticket with requirements for this proposed change? >> >> An existing ticket exists (https://devel.rtems.org/ticket/4272) for a GSoC >> project that defines a different approach where the conversion is held in the >> eco-system depending on data installed with the BSP. > > The approach is not that much different. The BSP installs an optional Python > script. This script could be added to the pkg-config information. I am happy with this. The command lets us defined a user interface at the command line interface while we figure out what works at the pkgconfig level. I suspect that may change and evolve and that may break users who depend directly on that data. Can we develop a suitable interface in pkg-config? The pkgconfig tool lets you query user specific variables which we can use then what? >> The `rtems-test` command can integrate an eco-system command (#4272) easily >> so I >> would need to understand why creating these binary images in the a build >> benefits the projects? I can see it benefiting niche custom testers users may >> have but not much more? > > The BSP knows best how to provide a proper boot image which could depend on > its BSP options (for example, memory locations). The most common task is > probably the creation of U-Boot images. Yes. Should these values be exported or should it be a "system" or "shell" command of some form? I am fine with a command being used however we need to specify its constraints? For example a shell command but is that the host OS shell or a POSIX shell etc? >> The reason an external command was created was to avoid build systems hacks >> being used to convert images forcing the project and any future additions to >> consider and develop an interface for exporting the needed information. >> Running >> the tests is one user of bootloader images but others exist such as EPICS >> which >> also needs to convert ELF to a bootloader compatible format. > > My driving factor for this stuff is that I would like to have U-Boot images > for test runs. I understand. It is weakness we have had for a long time. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
