[PATCH] spec/build/bsps: Fix blank variables

[Chris Johns]

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

> 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