[c8b35b1b] | 1 | # |
---|
| 2 | # $Id$ |
---|
| 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/<bsp>.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 <bsp>.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 |
---|
[0ff37e68] | 61 | forget to add all sources which do not get installed by automake |
---|
[c8b35b1b] | 62 | to automake's EXTRA_DIST, e.g. noinst_SCRIPTS, noinst_DATA have to be added |
---|
[0ff37e68] | 63 | to EXTRA_DIST. |
---|
[c8b35b1b] | 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 | |
---|