Automatic Re-Building of BSP

Ralf Corsepius corsepiu at faw.uni-ulm.de
Thu Feb 6 01:13:52 UTC 2003


Am Mit, 2003-02-05 um 23.21 schrieb gregory.menke at gsfc.nasa.gov:
> Don writes:
> 
>  > > 
>  > > > Trying to move on to bigger and better things, I found the bsp.h 
>  > needed
>  > > > tailoring.  Some PPC2A registers are not explicitly defined in the
>  > > > ppcn_60x BSP.  After making the changes and trying to make my "hello
>  > > > world pluss flash LEDs", I got compile errors indicative of the 
>  > bsp.h
>  > > > changes not being included.
>  > > 
>  > > Are you modifying the hello world in c/src/tests/samples or the
>  > > standalone example application version?  
>  > >  
>  > > Either way you can do a make clean in that particular directory.
>  > > I know this is what I do so unless Ralf enlightens us both, that
>  > > is all I know to offer.
>  > 
>  > Tried 'make clean', 'make all', and 'make' in the stand-alone directory 
>  > with no luck.
>  > 
> 
> When modifying a bsp, the dependencies sometimes don't make it all the
> way up to a top-level make. 
It depends on what you are referring to. --maintainer-mode only takes
care about dependencies between auto*-generated files, ie. Makefiles
etc.

Source-file dependencies normally are considered unless those which are
explicitly written into the Makefiles.

> One thing I do in this case is a 'make
> clean' at a conveniently low level in the bsp, 
> 
> (perhaps c/src/lib/libbsp/<whatever processor>/<whatever bsp>)
> 
> so a minimal set of files is deleted, then a top-level make is run.
> The now-larger set of deleted files will trip dependencies and cause
> the bsp to be rebuilt, but not rebuild all of rtems.  Its a little
> clumsy because of the make in 2 different locations, but you can
> always be clever and do things like;
> 
> make clean; pushd /opt/rtems/build/my-bsp; make install; popd
> 
> from the <whatever bsp> directory above.  That will delete the
> compiled bsp, jump to the top level and make install which will
> rebuild the bsp, relink whatever is necessary and install the
> libraries.  You'll still go thru the library assembly phase, but it
> avoids building the score/posix/networking trees.

It might surprize you: Since introduction of the cpukit there is not any
dependency [1] between cpukit/ (which comprizes score/posix and large
parts of networking) and a BSP.

>  > > > The way I understood things, enabling maintainer mode (--enable-
>  > > > maintainer-mode) caused any required files to be updated when a 
>  > make of
>  > > > the user code is performed.  Obviously, I am off base on this 
>  > notion!
See above.

>  > > > 
>  > > > In tweaking the BSP, do I need to rebuild it using the "verbose"
>  > > > approach shown above?  Did I miss something with --enable-
>  > maintainer-
>  > > > mode?  Is there a better way?
>  > > 
>  > > Ralf can probably explain it for sure.  But I am only positive that
>  > > --enable-maintainer-mode verifies configure* and Makefile* 
>  > dependencies
>  > > (those based upon auto* tools).
Exactly, but ... there also is my "very friend" "make depend", a make
target which is supposed to generate source-file dependencies.

Unfortunately "make depend" sometimes fails badly, but at least it's
better than nothing [2].

>  > So, for the time being a 'full' BSP build is probably the best 
>  > approach?
If using per-bsp-builts, currently yes.

However, there is the multilib approach:

./configure --target=<your-target> --enable-multilib
--enable-maintainer-mode --enable-rtemsbsp=<your-bsps>
make
[This will build a multilib'ed cpukit (librtemscpu.a) and the selected
bsps (Depending on your target and host, this can take several hours!)]

cd <cpu>/c/<bsp>
make depend

>From now on it should be sufficient to work from inside of this
directory, because the multilib'ed parts of RTEMS (cpukit) are supposed
to not depend on files inside of a BSP.


Ralf

[1] One exception: the setting originating from make/custom/<bsp.cfg>

[2] I had wanted to replace "make depend" by automake-dependency
tracking, but somebody at OAR had decided to reject this proposal, due
to other implications/side-effects this step would imply. :-(







More information about the users mailing list