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