On 10/3/2022 9:43 am, Joel Sherrill wrote: > On Wed, Mar 9, 2022 at 4:24 PM Heinz Junkes <jun...@fhi-berlin.mpg.de> > wrote: > >> Thanks for that. I've been struggling with this for a while ;-) >> >> But there is this comment in the file: >> “ >> # >> # BSP specific settings. To be included in application Makefiles >> # >> # This support will be removed from RTEMS. Please consider other >> # ways to build applications. >> # >> “ >> I thought this was no longer maintained and the "correct" way is now >> pkg-config? >> Or am I wrong here?
I do not think so. I pushed for removal because of the problems Makefile.inc creates and it was decided to add some support for backwards compatibility to the waf build system. Unfortunately we cannot generate fully compatible files for all users and so we are here again. This topic has been about for decades dating back to when Ralf attempted to add pkg-config support to the autoconf build system and realised the scale of the problem and how it was impossible to do. > pkg-config is better. I think Chris has mentioned issues with it but I > don't know what they might be. It is and I encourage users to move off Makefile.inc. Makefile.inc changes need to fit within a narrow window that models the sort of flags pkg-config encourages you to export. Older RTEMS versions generated a Makefile.inc that exported everything in an internal build and as a result we cannot determine what users depend on and if that is suitable or not to export. I am not sure what this patch generates. I would like to know before I agree to it. Ryan, would it be ok for you to post a generated Makefile.inc diff from this patch? Specifically I am not sure about RTEMS_HAS_NETWORKING. We may need this one because of backwards compatibility. In rtems_waf I check the opts header file: https://git.rtems.org/rtems_waf/tree/rtems.py#n307 https://git.rtems.org/rtems_waf/tree/rtems.py#n356 > Removing these is an ongoing debate. Ah ok ... hmmm ... > The rtems-examples are the only user > left within the RTEMS Project. And you can build them with waf. > > AFAIK they generally still work OK but you don't inherit the optimization > or warning CFLAGS like you once did. Correct. It was a mistake to have these included in Makefile.inc and as a result it is unfortunate applications depended on them. For example wanting to build an application with no optimisation often meant a local hack to Makefile.inc or rebuilding RTEMS. RTEMS's internal build configuration is just that, it's internal to it's build. Applications can and should have different configurations to the kernel. The only mandated compiler flags are for the ABI and that has been documented in the User Manual for a while now and we export those. > Unless there is a giant upswell of support, I'm prone to acquiesce and let > them be removed after 6. Sorry, they went away with the autoconf build system and so that means rtems5 was the last version with them. And I hope a ground swell comes with a complete audit of all BSP Makefile fragments and custom elements plus the list of what is used by users. :D It makes no sense to me to cherry pick some because they effect some users. We need to rip the band-aid off and get users to fix what they have. > But apparently you are using it. What's the scope of that? EPICS uses Makefile.inc in its build system. It has a BSP config and then the RTEMS specific make support includes Makefile.inc for the ABI flags. It does have the V_OPTIMISE etc but I am not sure how this effects an EPICS build. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
