Add extra variables to bsp.pc.in

[Chris Johns]

Add the following variables:

target
AS
CC
CXX
LD
RTEMS_CPU

[Sebastian Huber]

I use this in my simple Makefiles:

export AR = $(RTEMS_CPU)-rtems$(RTEMS_API)-ar
export AS = $(RTEMS_CPU)-rtems$(RTEMS_API)-as
export CC = $(RTEMS_CPU)-rtems$(RTEMS_API)-gcc --pipe
export CXX = $(RTEMS_CPU)-rtems$(RTEMS_API)-g++
export LD = $(RTEMS_CPU)-rtems$(RTEMS_API)-ld
export NM = $(RTEMS_CPU)-rtems$(RTEMS_API)-nm
export OBJCOPY = $(RTEMS_CPU)-rtems$(RTEMS_API)-objcopy
export RANLIB = $(RTEMS_CPU)-rtems$(RTEMS_API)-ranlib
export SIZE = $(RTEMS_CPU)-rtems$(RTEMS_API)-size
export STRIP = $(RTEMS_CPU)-rtems$(RTEMS_API)-strip

[Chris Johns]

And for CFLAGS?
How is RTEMS_CPU and RTEMS_API set?

[Chris Johns]

Oh I see the Makefile, sorry about that. I am sorry but that Makefile is far from simple and it repeats the flag set in RTEMS and is something I feel we cannot document. It is too difficult to manage.

[Sebastian Huber]

Replying to Chris Johns:

Oh I see the Makefile, sorry about that. I am sorry but that Makefile is far from simple and it repeats the flag set in RTEMS and is something I feel we cannot document. It is too difficult to manage.

Yes, I guessed that. My point is that if you start to export AS, CC, CXX, LD, then you should do this also for NM, OBJCOPY, RANLIB, SIZE and STRIP.

We should carefully think about what we export in these package config files. Once it is in the wild it is hard to pull back.

[Chris Johns]

Replying to Sebastian Huber:

Replying to Chris Johns:

Oh I see the Makefile, sorry about that. I am sorry but that Makefile is far from simple and it repeats the flag set in RTEMS and is something I feel we cannot document. It is too difficult to manage.

Yes, I guessed that.

To make this thread complete for anyone reviewing it, anything that includes a BSP .cfg file is fragile and can break as those files are not standardized, can be changed at any time as the demands of the RTEMS internal build system require, and are only useful when make is the application build system.

My point is that if you start to export AS, CC, CXX, LD, then you should do this also for NM, OBJCOPY, RANLIB, SIZE and STRIP.

Agreed, however adding all these steps deeper into the .m4 files and I did not want to do that at this point in time. If you think I should I can.

We should carefully think about what we export in these package config files. Once it is in the wild it is hard to pull back.

I agree. The patch I posted adds AS, CC, CXX and LD and target because they are supported in the configure scripts. The target can be used to create other tools. The issue is the other tools are not supported in the underlying .m4 support that is used via config.status to substitute the @@ tags in this file.

I was wanting to limit what is added to just the things I know are present and are needed to make a simple example build. I know it is not prefect but it does provide a way for us to document building a simple example in a way we can support into the future. I felt having that documentation was important as a user is asking on the users list about this. It is confusing to new users why the compiler does not just work like it does on Unix, Windows etc and we need to try and do better explaining this.

[Sebastian Huber]

Replying to Chris Johns:

Replying to Sebastian Huber:

Replying to Chris Johns:

Oh I see the Makefile, sorry about that. I am sorry but that Makefile is far from simple and it repeats the flag set in RTEMS and is something I feel we cannot document. It is too difficult to manage.

Yes, I guessed that.

To make this thread complete for anyone reviewing it, anything that includes a BSP .cfg file is fragile and can break as those files are not standardized, can be changed at any time as the demands of the RTEMS internal build system require, and are only useful when make is the application build system.

Yes, I agree.

My point is that if you start to export AS, CC, CXX, LD, then you should do this also for NM, OBJCOPY, RANLIB, SIZE and STRIP.

Agreed, however adding all these steps deeper into the .m4 files and I did not want to do that at this point in time. If you think I should I can.

Sorry, I didn't want to make things more complicated than they are already. The problem is you need OBJCOPY and RANLIB to create boot loader files and libraries.

We should carefully think about what we export in these package config files. Once it is in the wild it is hard to pull back.

I agree. The patch I posted adds AS, CC, CXX and LD and target because they are supported in the configure scripts. The target can be used to create other tools. The issue is the other tools are not supported in the underlying .m4 support that is used via config.status to substitute the @@ tags in this file.

If target can be used to create other tools, then providing also AS, etc. seems to be redundant to me.

I was wanting to limit what is added to just the things I know are present and are needed to make a simple example build. I know it is not prefect but it does provide a way for us to document building a simple example in a way we can support into the future. I felt having that documentation was important as a user is asking on the users list about this. It is confusing to new users why the compiler does not just work like it does on Unix, Windows etc and we need to try and do better explaining this.

Yes, I also thought about that and ended up with the TODO comment here:

​https://docs.rtems.org/branches/master/user/start/app.html

At the moment we just have a series of hacks which I didn't want do document and I did run out of time to work on it. I think we should pick up a couple of standard build systems, e.g. make (gmake), cmake, waf, SCons, Eclipse CDT internal builder, boost, etc. and try to build an RTEMS application with an application library and a post-link step to produce an U-Boot image.

[Chris Johns]

Replying to Sebastian Huber:

Replying to Chris Johns:

Replying to Sebastian Huber:

Replying to Chris Johns:

Oh I see the Makefile, sorry about that. I am sorry but that Makefile is far from simple and it repeats the flag set in RTEMS and is something I feel we cannot document. It is too difficult to manage.

Yes, I guessed that.

To make this thread complete for anyone reviewing it, anything that includes a BSP .cfg file is fragile and can break as those files are not standardized, can be changed at any time as the demands of the RTEMS internal build system require, and are only useful when make is the application build system.

Yes, I agree.

My point is that if you start to export AS, CC, CXX, LD, then you should do this also for NM, OBJCOPY, RANLIB, SIZE and STRIP.

Agreed, however adding all these steps deeper into the .m4 files and I did not want to do that at this point in time. If you think I should I can.

Sorry, I didn't want to make things more complicated than they are already. The problem is you need OBJCOPY and RANLIB to create boot loader files and libraries.

I think it a matter of adding them to here ...

​https://git.rtems.org/rtems/tree/c/src/aclocal/canonicalize-tools.m4

We should carefully think about what we export in these package config files. Once it is in the wild it is hard to pull back.

I agree. The patch I posted adds AS, CC, CXX and LD and target because they are supported in the configure scripts. The target can be used to create other tools. The issue is the other tools are not supported in the underlying .m4 support that is used via config.status to substitute the @@ tags in this file.

If target can be used to create other tools, then providing also AS, etc. seems to be redundant to me.

OK.

I was wanting to limit what is added to just the things I know are present and are needed to make a simple example build. I know it is not prefect but it does provide a way for us to document building a simple example in a way we can support into the future. I felt having that documentation was important as a user is asking on the users list about this. It is confusing to new users why the compiler does not just work like it does on Unix, Windows etc and we need to try and do better explaining this.

Yes, I also thought about that and ended up with the TODO comment here:

​https://docs.rtems.org/branches/master/user/start/app.html

At the moment we just have a series of hacks which I didn't want do document and I did run out of time to work on it. I think we should pick up a couple of standard build systems, e.g. make (gmake), cmake, waf, SCons, Eclipse CDT internal builder, boost, etc. and try to build an RTEMS application with an application library and a post-link step to produce an U-Boot image.

I understand. I cannot find something that is not specific to a build system to use other than pkg-config. My hope is pkg-config support is most major build systems will provide a way to grow build system support. This is what I made a app section for the User manual. We need something.

[Sebastian Huber]

This is still an issue in the new build system. We need a proper pkg-config support.

[Chris Johns]

It would be good to add support the post linking. A way to export symbols or labels used to generate target loadable images, ie args to mkimage for uboot.