Christian Mauderer commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/515#note_125267 Yes, it's definitively not an optimal process. But it's the one that is currently used. So this BSP follows the process. A method that I would personally prefer are submodules. But of course that has limitations too like: * How to integrate RTEMS specific changes? * How to make sure that the submodules are initialized and on the right version? * How to integrate them into the release process? Unfortunately I don't have good answers to these. Another method could be to build vendor libraries separately and link RTEMS against it. That would mean that we never know the exact version. Additionally, tests can't be build any more without building these vendor libraries in advance. But I think that discussion is not something that we should start as a side-note to a new BSP patch. If it is a problem, we most likely should create a separate ticket for it and find a good solution there. Is this a blocking point for the new BSP for you? -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/515#note_125267 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs
