| 1 |
30 |
unneback |
#
|
| 2 |
|
|
# $Id: MERGE.PROCEDURE,v 1.2 2001-09-27 11:59:36 chris Exp $
|
| 3 |
|
|
#
|
| 4 |
|
|
|
| 5 |
|
|
When adding a BSP to the RTEMS tree, there is usually some cleanup
|
| 6 |
|
|
to be done.
|
| 7 |
|
|
|
| 8 |
|
|
=========================================================================
|
| 9 |
|
|
|
| 10 |
|
|
Add an entry to ACKNOWLEDGEMENTS.
|
| 11 |
|
|
|
| 12 |
|
|
Send letter with permission to distribute the BSP with RTEMS.
|
| 13 |
|
|
|
| 14 |
|
|
Verify all test link.
|
| 15 |
|
|
|
| 16 |
|
|
Remove compilation warnings.
|
| 17 |
|
|
|
| 18 |
|
|
Make sure that all files submitted are really intended to do into
|
| 19 |
|
|
the distribution. For example, you may have a myfile.S produced by
|
| 20 |
|
|
gcc -S myfile.c.
|
| 21 |
|
|
|
| 22 |
|
|
=========================================================================
|
| 23 |
|
|
This section of the file describes how to run the acpolish script to
|
| 24 |
|
|
check Makefile style and construction compliance.
|
| 25 |
|
|
|
| 26 |
|
|
The BSP's still apply RTEMS's old autoconf configuration. The only thing
|
| 27 |
|
|
that have changed are some details inside the Makefile.ins and some details
|
| 28 |
|
|
in make/custom/.cfg. Acpolish should be able to convert 4.0.0
|
| 29 |
|
|
Makefile.in into new style Makefile.ins. However, sometimes acpolish has
|
| 30 |
|
|
problems/contains bugs, which require manual intervention. There is no tool
|
| 31 |
|
|
to adapt a BSP's .cfg, but this shouldn't be a problem for you.
|
| 32 |
|
|
|
| 33 |
|
|
Therefore, this is my coarse recipe to merge BSPs is:
|
| 34 |
|
|
|
| 35 |
|
|
1. Copy a BSP's files and directories to appropriate directories.
|
| 36 |
|
|
|
| 37 |
|
|
2. Manually run acpolish on each Makefile.in and check the output, eg:
|
| 38 |
|
|
cd some_subdir
|
| 39 |
|
|
/path_to_RTEMS/tools/update/acpolish < Makefile.old > Makefile.new
|
| 40 |
|
|
|
| 41 |
|
|
Check Makefile.new for correctness, evtl. edit it, then re-run acpolish
|
| 42 |
|
|
again:
|
| 43 |
|
|
/path_to_RTEMS/tools/update/acpolish < Makefile.new > Makefile.in
|
| 44 |
|
|
|
| 45 |
|
|
Compare Makefile.new against Makefile.in. These must not differ, if they
|
| 46 |
|
|
do, edit Makefile.new until the Makefile.in generated by re-running
|
| 47 |
|
|
acpolish on Makefile.new does not differ from the freshly generated
|
| 48 |
|
|
Makefile.in. If they differ permanently, then you probably are affected
|
| 49 |
|
|
bugs in acpolish (This happens for some styles of conditionals).
|
| 50 |
|
|
|
| 51 |
|
|
This sounds much worser than it actually is, because the bugs in acpolish
|
| 52 |
|
|
only hit very seldom. Furthermore, BSPs normally only contain a few
|
| 53 |
|
|
Makefile.ins, therefore individually running acpolish should be tolerable.
|
| 54 |
|
|
|
| 55 |
|
|
3. If a BSP contains tools, you have to convert its configuration to
|
| 56 |
|
|
automake manually. Typically these tools are rather simple, therefore a
|
| 57 |
|
|
tool's configuration applies standard automake Makefile.ams and
|
| 58 |
|
|
configure.ins. RTEMS should contain enough examples which could serve as
|
| 59 |
|
|
templates for this (My advice: Try to avoid preinstallation and
|
| 60 |
|
|
installation to the temporary installation tree whenever possible; Don't
|
| 61 |
|
|
forget to add all sources which do not get installed by automake
|
| 62 |
|
|
to automake's EXTRA_DIST, e.g. noinst_SCRIPTS, noinst_DATA have to be added
|
| 63 |
|
|
to EXTRA_DIST.
|
| 64 |
|
|
|
| 65 |
|
|
Please let me know if you meet problems and if we/I can fix them. I
|
| 66 |
|
|
consider acpolish to be an internal developer's and maintainer's helper
|
| 67 |
|
|
script, which was never intended to be of general use, which is why I am
|
| 68 |
|
|
not much concerned about bugs in it.
|
| 69 |
|
|
|
| 70 |
|
|
Ralf.
|
| 71 |
|
|
|
| 72 |
|
|
=========================================================================
|
| 73 |
|
|
|
