Automatic Re-Building of BSP

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

note the use of ; instead of &&, this causes the command series to be
completed regardless of errors so you will be in the right place to
make clean for the next pass.

I am assuming you're using a build directory different from the
install directory; a temp directory in which configure generates a
tree that make uses to compile, the results of which are installed
into a different tree that is intended for use by appliation software.
The make steps above want to be done in the temp tree; you edit in the
source tree and the install tree gets the final result.


 > 
 > > 
 > > > 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).
 > 
 > So, for the time being a 'full' BSP build is probably the best 
 > approach?  I guess my concern is that there might be a problem re-
 > building the BSP on top of an existing version of the same BSP.  (Maybe 
 > I am too conditioned to the Windows app approach that 'highly 
 > recommends' previous versions be un-installed before installing new 
 > versions.  ;)  )
 > 

Mod the dependency stuff above, bsp tweaks should compile just fine-
no special configure parameters should be required unless you're
creating a new bsp or adding files.  I'm not sure what you mean about
existing vs older versions of the bsp in the same directory.

If you're modifying the test programs, its probably time to start a
project in your own tree- you'll find it much easier to work with.

Gregm