[RTEMS Project] #3729: Add extra variables to bsp.pc.in

[RTEMS trac]

#3729: Add extra variables to bsp.pc.in
-------------------------+--------------------------
 Reporter:  Chris Johns  |       Owner:  Chris Johns
     Type:  defect       |      Status:  assigned
 Priority:  normal       |   Milestone:  5.1
Component:  build        |     Version:  5
 Severity:  normal       |  Resolution:
 Keywords:               |  Blocked By:
 Blocking:               |
-------------------------+--------------------------

Comment (by Sebastian Huber):

 Replying to [comment:5 Chris Johns]:
 > Replying to [comment:4 Sebastian Huber]:
 > > Replying to [comment:3 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.

--
Ticket URL: <http://devel.rtems.org/ticket/3729#comment:6>
RTEMS Project <http://www.rtems.org/>
RTEMS Project