Automatic Re-Building of BSP

[Don]

Greg,

Between Joel explaining to me how to find the right samples directory 
and your comments, I think I might be able to make some headway.  My 
biggest problem, as Joel has probably concluded, is keeping the 
directory structure straight!

Speaking of directory structures, you mention " ....... probably time 
to start a project in your own tree ......."; would you elaborate on 
creating a project tree?  As I mentioned, I seem to be directory 
challenged.

Thanks!

Don






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