[RTEMS Project] #3729: Add extra variables to bsp.pc.in
trac at rtems.org
Tue Apr 2 05:13:03 UTC 2019
#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:
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
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
Yes, I also thought about that and ended up with the TODO comment here:
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
Ticket URL: <http://devel.rtems.org/ticket/3729#comment:6>
RTEMS Project <http://www.rtems.org/>
More information about the bugs