[PATCH] spec/build/bsps: Fix blank variables
Ryan Long
ral051 at oarcorp.com
Fri Mar 11 15:22:27 UTC 2022
On 3/9/2022 6:44 PM, Chris Johns wrote:
> On 10/3/2022 9:43 am, Joel Sherrill wrote:
>> On Wed, Mar 9, 2022 at 4:24 PM Heinz Junkes <junkes at 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
Makefile.inc diff
< RTEMS_HAS_POSIX_API = yes
---
> RTEMS_HAS_POSIX_API =
make/bsp.cfg diff
< HAS_MP = no
---
> HAS_MP =
16c16
< HAS_POSIX_API = yes
---
> HAS_POSIX_API =
31c31
< HAS_NETWORKING = no
---
> HAS_NETWORKING =
make/target.cfg diff
< RTEMS_HAS_MULTIPROCESSING = no
< RTEMS_HAS_POSIX_API = yes
---
> RTEMS_HAS_MULTIPROCESSING =
> RTEMS_HAS_POSIX_API =
36c36
< RTEMS_HAS_NETWORKING = no
---
> RTEMS_HAS_NETWORKING =
>
>> 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
More information about the devel
mailing list