|
@@ -0,0 +1,169 @@
|
|
1
|
+Project hierarchy guidelines
|
|
2
|
+============================
|
|
3
|
+
|
|
4
|
+
|
|
5
|
+Abstract
|
|
6
|
+--------
|
|
7
|
+
|
|
8
|
+One thing that every growing software project has to deal with at some
|
|
9
|
+point is organizing files in their repository: where to put source files?
|
|
10
|
+Where to put tests? Packaging templates (.spec, debian/control)?
|
|
11
|
+Build scripts? Project guidelines?
|
|
12
|
+
|
|
13
|
+What I've seen most often is generally one of these:
|
|
14
|
+
|
|
15
|
+ * Just don't care and drop everything in the root directory.
|
|
16
|
+
|
|
17
|
+ * This code is part of a project which already has guidelines so
|
|
18
|
+ just follow them.
|
|
19
|
+
|
|
20
|
+ * Platform this code built upon already has guidelines so just follow
|
|
21
|
+ them.
|
|
22
|
+
|
|
23
|
+ * Don't try to solve that, it's a waste of time.
|
|
24
|
+
|
|
25
|
+ * Try to solve that iteratively: every now and then, realize that
|
|
26
|
+ the hierarchy is confusing so start. Twiddle, tweak, frobnicate,
|
|
27
|
+ tweak, frobnicate, twiddle...
|
|
28
|
+
|
|
29
|
+Each of above approaches has its cons and (arguably) pros, the mere
|
|
30
|
+decision which approach to apply is not easy, so one easily gets into
|
|
31
|
+a decision paralysis.
|
|
32
|
+
|
|
33
|
+This document is an attempt to help people avoid that and get at least
|
|
34
|
+some starting point when putting things together.
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+Guidelines
|
|
38
|
+----------
|
|
39
|
+
|
|
40
|
+### Root (README et al.) ###
|
|
41
|
+
|
|
42
|
+It's good to keep as little files here as possible, but few names are
|
|
43
|
+already become de-facto standard.
|
|
44
|
+
|
|
45
|
+Every decent project has a *README* file in the root folder. You can name
|
|
46
|
+it *README.md*, *README.rst*, but it should be the first thing everyone
|
|
47
|
+reads. Normally, a brief introduction and installation instructions,
|
|
48
|
+unless they are already provided under *INSTALL* file.
|
|
49
|
+
|
|
50
|
+Among other common files here are LICENSE, Makefile, CHANGELOG or similar
|
|
51
|
+files that are chiefly related to a project as a whole.
|
|
52
|
+
|
|
53
|
+
|
|
54
|
+### src ###
|
|
55
|
+
|
|
56
|
+Everything that is supposed to be (directly or in some "built" form)
|
|
57
|
+deployed on the target host goes under `src`.
|
|
58
|
+
|
|
59
|
+Under this folder, it makes sense to have files divided in sub-folders
|
|
60
|
+named reminiscent to the target paths. For example, host configuration
|
|
61
|
+files should be under `src/etc`, library source files under `src/lib`,
|
|
62
|
+future binaries under `src/bin`, future manpages to `src/man`...
|
|
63
|
+
|
|
64
|
+Note that it does not matter whether there is some significant build
|
|
65
|
+procedure to happen; it's OK if most of the files here are just verbatim
|
|
66
|
+copies ready to be deployed to the target.
|
|
67
|
+
|
|
68
|
+
|
|
69
|
+### tests ###
|
|
70
|
+
|
|
71
|
+Your test suite goes here. How to structure files under this directory
|
|
72
|
+will most probably depend on the test framework you use.
|
|
73
|
+
|
|
74
|
+
|
|
75
|
+### artifacts ###
|
|
76
|
+
|
|
77
|
+If your test suite creates files that you usually need to review,
|
|
78
|
+this is a good place. Subdirectories here should bear a timestamp in
|
|
79
|
+a human-readable and sortable timestamp format (such as ISO 8601).
|
|
80
|
+
|
|
81
|
+Note that normally this directory will never exist in a freshly cloned
|
|
82
|
+repository and it's likely to be excluded from version control system
|
|
83
|
+via file such as *.gitignore*.
|
|
84
|
+
|
|
85
|
+
|
|
86
|
+### notes ###
|
|
87
|
+
|
|
88
|
+Documentation related to your project. Evertything from guidelines to
|
|
89
|
+newcomer howtos, style guides, design notes, philpsophy articles...
|
|
90
|
+
|
|
91
|
+
|
|
92
|
+### utils ###
|
|
93
|
+
|
|
94
|
+Any build scripts and utilities that are only useful for your project
|
|
95
|
+developers and testers.
|
|
96
|
+
|
|
97
|
+
|
|
98
|
+### packaging ###
|
|
99
|
+
|
|
100
|
+Templates to help package maintainers. Templates for RPM SPEC files,
|
|
101
|
+debian control directories or similar data can live here.
|
|
102
|
+
|
|
103
|
+Note that in many cases distributions like Debian or Fedora may not
|
|
104
|
+be able to directly use these files, but they can be a good start for
|
|
105
|
+e.g. creating unofficial .deb files.
|
|
106
|
+
|
|
107
|
+[MKit][1] already provides features that can help generate such files.
|
|
108
|
+
|
|
109
|
+ [1]: https://github.com/AloisMahdal/mkit
|
|
110
|
+
|
|
111
|
+
|
|
112
|
+Example
|
|
113
|
+-------
|
|
114
|
+
|
|
115
|
+A "living" example: [shellfu][2]:
|
|
116
|
+
|
|
117
|
+ .
|
|
118
|
+ ├── LICENSE # \
|
|
119
|
+ ├── Makefile # Pretty much standard files...
|
|
120
|
+ ├── README.md # /
|
|
121
|
+ ├── artifacts
|
|
122
|
+ │ ├── artifacts-inigrep_inigrep-20161202-073432
|
|
123
|
+ │ │ ├── TF_ENUMERATED_SUBTESTS
|
|
124
|
+ │ │ ├── TF_FILTERED_SUBTESTS
|
|
125
|
+ │ │ ├── TF_RUN
|
|
126
|
+ │ │ ├── oracle # \
|
|
127
|
+ │ │ │ └── ... # artifacts are now huge since
|
|
128
|
+ │ │ ├── result # I ran a lot of tests recently
|
|
129
|
+ │ │ │ └── ... # /
|
|
130
|
+ │ │ └── test
|
|
131
|
+ │ │ └── ...
|
|
132
|
+ │ └── artifacts-shellfu_api-20161202-081440
|
|
133
|
+ │ └── ...
|
|
134
|
+ ├── mkit.ini # <- MKit meta-data file
|
|
135
|
+ ├── notes # <- my design notes, although
|
|
136
|
+ │ └── style.md # most are still in my head :)
|
|
137
|
+ ├── packaging
|
|
138
|
+ │ ├── debian # \
|
|
139
|
+ │ │ ├── changelog # only used for ad-hoc, testing and
|
|
140
|
+ │ │ ├── control # alpha RPMs and .deb's
|
|
141
|
+ │ │ └── ... # (so far, probably for good)
|
|
142
|
+ │ └── shellfu.spec # /
|
|
143
|
+ ├── src
|
|
144
|
+ │ ├── bin # \
|
|
145
|
+ │ │ ├── shellfu-doc # here most of the "meat" lives,
|
|
146
|
+ │ │ └── shellfu-get.skel # only about two files really need
|
|
147
|
+ │ ├── complete-devel.bash # any "building"
|
|
148
|
+ │ ├── complete.bash #
|
|
149
|
+ │ ├── include-bash # notice that tree here does
|
|
150
|
+ │ │ └── ... # not attempt to strictly follow
|
|
151
|
+ │ ├── include-sh # final placement, jsut hinting
|
|
152
|
+ │ │ └── ... # is enough
|
|
153
|
+ │ └── shellfu.sh.skel # /
|
|
154
|
+ ├── tests # \
|
|
155
|
+ │ ├── TF_HEADER # another "huge" directory
|
|
156
|
+ │ ├── inigrep_inigrep # structure, the test suite
|
|
157
|
+ │ │ ├── TF_RUN #
|
|
158
|
+ │ │ ├── oracle # hierarchy is influenced by TFKit
|
|
159
|
+ │ │ │ └── ... # which itself is actually embedded
|
|
160
|
+ │ │ └── test # under `utils` directory below
|
|
161
|
+ │ │ └── ... # /
|
|
162
|
+ │ └── ... #
|
|
163
|
+ └── utils # \
|
|
164
|
+ ├── mkit # all build scripts live here; actually just
|
|
165
|
+ │ └── ... # MKit and TFKit; note that TFKit lives apart
|
|
166
|
+ └── tfkit # from the suite (they meet often, though ;))
|
|
167
|
+ └── ... # /
|
|
168
|
+
|
|
169
|
+ [2]: https://github.com/AloisMahdal/shellfu
|