[Bug 1675] mcf5329 BSP post-link conversion broken
bugzilla-daemon at rtems.org
bugzilla-daemon at rtems.org
Tue Aug 17 02:15:57 CDT 2010
--- Comment #10 from Chris Johns <chrisj at rtems.org> 2010-08-17 02:15:56 CDT ---
(In reply to comment #9)
> (In reply to comment #7)
> > Would it be possible for you to describe the basic approach ?
> My utlimate goal was to eliminate make-exe in such a way standard automake LINK
> rules would build everything a BSP would need, aiming at eliminating inclusion
> of *.cfg's in Makefile.am's
> (This is another long term persisting weakness RTEMS suffers from).
That would be fantastic and a great step forward. Would doing this allow
integration into any "standard" build system ?
> To achieve this, I had started to encapsulate all right-hand sides of make-exe
> into scripts and to try generalizing them into one per-target tool.
> IIRC, this plan failed, due to several issues interacting:
> - Lack of conventions regarding of suffixes/suffix rules.
> Meanwhile, introduction of the *.ralf's (BTW: I hate this suffix) might have
> lifted some of the issues, I had then.
If we do not create *.ralf files then we do not need the suffix.
Does this mean RTEMS stops at the linker output and the scripts (or what-ever)
under the control of the user takes over ?
> - People overloading *.cfgs with more and more options.
> Very annoying in this context: The RTEMS Makefile-templates.
Agreed. I see scripts also having this issue over time. I can see some getting
little custom additions and differences which over time create new problems and
there being no real method of checking they are working and have not rotted.
> Back then, my expectation had been in long terms to end up with an linker
> wrapper script or similar.
Do you mean a tool, for example called 'rtems-link', that was smart enough to
link and handle any BSP post-link processing (ie calling a script etc) ?
> However, this plan failed and resorted to gradually address the "small
> problems" inside by more and more formalizing Makefile.ams.
The problem I see us attempting to solve is the capturing of the meta-data type
information (for want of a better term) that describes the target or debugger
friendly output and all the specifics needed to create it. Not having it as
part of the BSP would be a loss of valuable information.
As an aside, I am having a similar sort of issue with the simulator scripts in
rtems-testing. They are great scripts but there are lots of them so installing
them into a 'bin' directory has issues. The script are common to a number of
BSPs. The issue here is which script is for which BSP ? I need some sort of
configuration data (meta-data???) in the BSP somewhere that allows a single
command called 'rtems-test' control this. While pondering this I did wonder if
the 'rtems-test' command could handle the convert (currently post-link) phase
when running the test. It would make for a faster build of RTEMS (less disk IO)
and the file could be cleaned up after the test lowering the disk usage.
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
More information about the rtems-bugs