deriving BSP from powerpc/shared

[Till Straumann]

Ralf Corsepius wrote:
> On Fri, 2005-10-14 at 14:57 -0700, Till Straumann wrote:
> 
>>I have problems with creating a new BSP that inherits from powerpc/shared.
>>
>>In the usual way, the BSP inherits from the shared area by using VPATH
>>and overrides specific files by providing its own version which is found
>>first on VPATH.
> 
> Sorry, I have to disagree: "VPATH is evil", and relying on VPATHS is
> "bad, bad, bad design".

I agree (also with your statement further down about libraries + APIs) - 
but it's just the way it is right now...

> 
> 
>>This works fine  for C files but the semantics for headers are different:
>>The Makefile.ams in the shared area actually cause some of the shared
>>headers to be installed --> during the 'preinstall' step, the 'shared' 
>>headers are installed and *not* the BSP specific ones.
> 
> I don't understand, what you are referring to.

Never mind - I found what I was looking for
[libbsp/powerpc/configure.ac:
  AM_CONDITIONAL(need_shared, test "$RTEMS_BSP_FAMILY" = 
"motorola_powerpc")]

unless the RTEMS_BSP_FAMILY is listed here, the build process
doesn't descend into the shared subdirs...

T.

> c/src/lib/libbsp/powerpc/shared/Makefile.am on CVS-trunk doesn't install
> anything.
> 
> 
>>Shouldn't the 'shared' area just be a mere repository for files and the
>>'make' process never really build anything in the 'shared' area?
> 
> Well, in an ideal world, there would not be any "shared code", there
> would be libraries, BSPs would like to link into and headers specifying
> APIs.
> 
> 
>>The BSP would then have to explicitely mention all the files it needs/wants
>>and it has complete control.
> 
> That's the current status on CVS-trunk.
> 
> 
>>How would you, Ralf, address this problem?
> 
> By, entirely abandoning shared code and replacing it with libraries with
> a properly defined API.
> 
> Ralf
> 
> 
>