[Bug 1675] mcf5329 BSP post-link conversion broken

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1675

--- 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.
>

Ok.

> 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.