| 6 |
7u83 |
1 |
Moving Out Tools
|
|
|
2 |
================
|
|
|
3 |
|
|
|
4 |
The process of moving out a tool to its own independent source tree is
|
|
|
5 |
expected to be essentially the same for each program. We'll take sid(1)
|
|
|
6 |
as an example:
|
|
|
7 |
|
|
|
8 |
1. Move out /tendra/utilities/sid to /sid/src
|
|
|
9 |
2. Make /sid/mk an svn:externals reference to /tendra/mk
|
|
|
10 |
3. Make /sid/build an svn:externals reference to /tendra/src/build
|
|
|
11 |
4. Provide a .mk file in /tendra/mk such that sid et al are able to
|
|
|
12 |
build using whichever compiler is around
|
|
|
13 |
|
|
|
14 |
|
|
|
15 |
Externals
|
|
|
16 |
---------
|
|
|
17 |
|
|
|
18 |
Our goal for separating these tools is to keep them semantically
|
|
|
19 |
distinct from each other. However, there're a few things that we still
|
|
|
20 |
wish to share between them, without compromising this separation.
|
|
|
21 |
|
|
|
22 |
For example, the build system is expected to be identical for each,
|
|
|
23 |
as there is no need to duplicate effort. Having multiple copies of this
|
|
|
24 |
would be a maintenance nightmare.
|
|
|
25 |
|
|
|
26 |
Subversion's 'externals' feature is our chosen method of keeping things
|
|
|
27 |
in one place, yet still separated to each program. This provides for
|
|
|
28 |
one centralised location containing the build system, and a link from
|
|
|
29 |
each program that makes use of it. When checked out, these trees will
|
|
|
30 |
automatically bring down the build system, too.
|
|
|
31 |
|
|
|
32 |
This is only visible to people working directly with Subversion; users
|
|
|
33 |
(when eventually we have some!) are not aware that the build system is
|
|
|
34 |
actually brought down by svn:externals: it simply appears present in
|
|
|
35 |
the archived snapshot.
|
|
|
36 |
|
|
|
37 |
Similarly during tagging, externals are pointed at a stable tag, before
|
|
|
38 |
the tag of the tool's trunk is made.
|
|
|
39 |
|
|
|
40 |
|
|
|
41 |
Building
|
|
|
42 |
--------
|
|
|
43 |
|
|
|
44 |
The system to build portably should be mostly be in place, since
|
|
|
45 |
bootstrapping process uses the same principle: to use whichever compiler
|
|
|
46 |
is available.
|
|
|
47 |
|
|
|
48 |
The current idea for approaching this, is to construct a new mk file
|
|
|
49 |
intended for building these programs. This is expected to be in essence
|
|
|
50 |
fairly similar to the bootstrap file.
|
|
|
51 |
|