[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: deriving BSP from powerpc/shared

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