1 | .. comment: Copyright (c) 2016 Chris Johns <chrisj@rtems.org> |
---|
2 | .. comment: All rights reserved. |
---|
3 | |
---|
4 | .. _prefixs: |
---|
5 | |
---|
6 | Prefixes |
---|
7 | ======== |
---|
8 | |
---|
9 | You will see the term **prefix** referred to though out this documentation and |
---|
10 | in a wide number of software packages you can download from the internet. A |
---|
11 | **prefix** is a path on your computer a software package is built and installed |
---|
12 | under. Packages that have a **prefix** will place all parts under the *prefix |
---|
13 | path*. On a host computer like Linux the packages you install from your |
---|
14 | distribution typically use a platform specific standard *prefix*. For example |
---|
15 | on Linux it is :file:`/usr` and on FreeBSD it is :file:`/usr/local`. |
---|
16 | |
---|
17 | We recommend you **do not** use the standard *prefix* when installing RTEMS |
---|
18 | Tools. If you are building the tools as a normal user and not as ``root`` the |
---|
19 | RTEMS Source Builder (RSB) will fail if the *prefix* is not writable. We |
---|
20 | recommend you leave the standand *prefix* for the packages your operating |
---|
21 | system installs. |
---|
22 | |
---|
23 | A further reason not use the standard *prefix* is to allow more than one |
---|
24 | version of RTEMS to exist on your host machine at a time. The ``autoconf`` and |
---|
25 | ``automake`` tools required by RTEMS are not versioned and vary between RTEMS |
---|
26 | versions. If you use a single *prefix* there is a chance things from different |
---|
27 | versions may interact. This should not happen but it could. |
---|
28 | |
---|
29 | For POSIX or Unix hosts the RTEMS Project uses :file:`/opt/rtems` as a standard |
---|
30 | *prefix*. We view this *prefix* as a production level path and we place |
---|
31 | development versions under a different *prefix* away from the production |
---|
32 | versions. Under this top level *prefix* we place the various versions we need |
---|
33 | for development, for example the version 4.11.0 the *prefix* would be |
---|
34 | :file:`/opt/rtems/4.11.0`. If an update called 4.11.1 is released the *prefix* |
---|
35 | would be :file:`/opt/rtems/4.11.1`. These are recommendations and the choice of |
---|
36 | what you use is entirly yours. You may decide to have a single path for all |
---|
37 | RTEMS 4.11 releases of :file:`/opt/rtems/4.11`. |
---|
38 | |
---|
39 | For Windows a typical prefix is :file:`C:\\opt` and as an MSYS2 path this is |
---|
40 | :file:`/c/opt`. |
---|
41 | |
---|
42 | .. _project_sandboxing: |
---|
43 | |
---|
44 | Project Sandboxing |
---|
45 | ================== |
---|
46 | |
---|
47 | Project specific sandboxes let you have a number of projects running in |
---|
48 | parallel with each project in its own sandbox. You simlpy have a prefix per |
---|
49 | project and under that prefix you create a simple yet repeatable structure. |
---|
50 | |
---|
51 | As an exapmle lets say I have a large disk mounted under :file:`/bd` for *Big |
---|
52 | Disk*. As ``root`` create a directory called ``projects`` and give the |
---|
53 | directory suitable permissions to be writable by you as a user. |
---|
54 | |
---|
55 | Lets create a project sandbox for my *Box Sorter* project. First create a |
---|
56 | project directory called :file:`/bd/projects/box-sorter`. Under this create |
---|
57 | :file:`rtems` and under that create :file:`rtems-4.11.0`. Under this path you |
---|
58 | can follow the :ref:`released-version` procedure to build a tool set using the |
---|
59 | prefix of :file:`/bd/projects/box-sorter/rtems/4.11.0`. You are free to create |
---|
60 | your project specific directories under :file:`/bd/projects/box-sorter`. |
---|
61 | |
---|
62 | A variation of this is to have a single set of *production* tools and RTEMS |
---|
63 | BSPs on the disk under :file:`/bd/rtems` you can share between your |
---|
64 | projects. The top level directories would be: |
---|
65 | |
---|
66 | :file:`/bd/rtems` |
---|
67 | The top path to production tools and kernels. |
---|
68 | |
---|
69 | :file:`/bd/rtems/4.11.0` |
---|
70 | Production prefix for RTEMS 4.11.0 compiler, debuggers, tools and Board |
---|
71 | Support Packages (BSPs). |
---|
72 | |
---|
73 | :file:`/bd/projects` |
---|
74 | Project specific development trees. |
---|
75 | |
---|
76 | :file:`/bd/projects/box-sorter` |
---|
77 | Box Sorter project sandbox. |
---|
78 | |
---|
79 | A further variation is to use the ``--without-rtems`` option with the RSB to |
---|
80 | not build the BSPs when building the tools and to buld RTEMS specifically for |
---|
81 | each project. This lets you have a production tools installed at a top level on |
---|
82 | your disk and each project can have a specific and possibly customised version |
---|
83 | of RTEMS. The top level directories would be: |
---|
84 | |
---|
85 | :file:`/bd/rtems` |
---|
86 | The top path to production tools and kernels. |
---|
87 | |
---|
88 | :file:`/bd/rtems/4.11.0` |
---|
89 | Production prefix for RTEMS 4.11.0. |
---|
90 | |
---|
91 | :file:`/bd/rtems/4.11.0` |
---|
92 | Production prefix for RTEMS 4.11.0 compiler, debuggers and tools. |
---|
93 | |
---|
94 | :file:`/bd/projects` |
---|
95 | Project specific development trees. |
---|
96 | |
---|
97 | :file:`/bd/projects/box-sorter` |
---|
98 | Box Sorter project sandbox. |
---|
99 | |
---|
100 | :file:`/bd/projects/box-sorter/rtems` |
---|
101 | Box Sorter project's custom RTEMS kernel source and installed BSP. |
---|
102 | |
---|
103 | If there is an RTEMS kernel you to share between projects you can move this to |
---|
104 | a top level and share. In this case you will end up with: |
---|
105 | |
---|
106 | :file:`/bd/rtems` |
---|
107 | The top path to production tools and kernels. |
---|
108 | |
---|
109 | :file:`/bd/rtems/4.11.0` |
---|
110 | Production prefix for RTEMS 4.11.0. |
---|
111 | |
---|
112 | :file:`/bd/rtems/4.11.0/tools` |
---|
113 | Production prefix for RTEMS 4.11.0 compiler, debuggers and tools. |
---|
114 | |
---|
115 | :file:`/bd/rtems/4.11.0/bsps` |
---|
116 | Production prefix for RTEMS 4.11.0 Board Support Packages (BSPs). |
---|
117 | |
---|
118 | :file:`/bd/projects` |
---|
119 | Project specific development trees. |
---|
120 | |
---|
121 | :file:`/bd/projects/box-sorter` |
---|
122 | Box Sorter project sandbox. |
---|
123 | |
---|
124 | The project sandoxing approach allows you move a specific production part into |
---|
125 | the project's sandbox to allow you to customise it. This is useful if you are |
---|
126 | testing new relesaes. The typical dependency is the order listed above. You can |
---|
127 | test new RTEMS kernels with production tools but new tools will require you |
---|
128 | build the kernel with them. Release notes with each release will let know |
---|
129 | what you need to update. |
---|
130 | |
---|
131 | If the machine is a central project development machine simply replace |
---|
132 | :file:`projects` with :file:`users` and give each user a personal directory. |
---|