[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Automatic Re-Building of BSP
- Date: 06 Feb 2003 02:13:52 +0100
- From: corsepiu at faw.uni-ulm.de (Ralf Corsepius)
- Subject: Automatic Re-Building of BSP
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
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  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!
> > > >
> > > > 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 .
> > 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
[This will build a multilib'ed cpukit (librtemscpu.a) and the selected
bsps (Depending on your target and host, this can take several hours!)]
>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.
 One exception: the setting originating from make/custom/<bsp.cfg>
 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. :-(