Browse Source

Add hierarchy.md

Twiddled, frobnicated and tweaked (in any order) countless times, now
finally established for over a year now, I'm hereby paying the debt of
sharing this.
Alois Mahdal 7 years ago
parent
commit
ba30870d02
2 changed files with 170 additions and 0 deletions
  1. 1
    0
      README.md
  2. 169
    0
      guidelines/hierarchy.md

+ 1
- 0
README.md View File

@@ -7,6 +7,7 @@ Index
7 7
 -----
8 8
 
9 9
  *  [Markdown](guidelines/markdown.md)
10
+ *  [Software project hierarchy](guidelines/hierarchy.md)
10 11
 
11 12
 
12 13
 Author

+ 169
- 0
guidelines/hierarchy.md View File

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