-
-
Notifications
You must be signed in to change notification settings - Fork 242
/
HACKING
81 lines (54 loc) · 3.19 KB
/
HACKING
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
# Project naming and copyright attribution:
* "The MacPorts Project" is the string that shall be used wherever
there's a need to reference our project name, such as in copyright
notices.
* A developer or contributor is advised to attribute themself a copyright
notice if they are contributing a full new source file or a full
new feature to an already existing source file in the "base"
component of our repository.
* An exception to this rule is our Portfiles, since they are partly
meant for human eyes consumption and the boilerplate header comments
should be kept down to a minimum
* A copyright notice attributed to our group name, "The MacPorts
Project", should also be added to these source files (if not already
there) if they're being uploaded to the "base" component of our
repository, since as such they are being contributed to the project.
# Commits to the "base" component of the repository:
* Commits with user-visible effect made to the "base" component of the
repository should be accompanied by a corresponding entry in the
base/ChangeLog file, with references to pertinent Trac ticket
numbers and git commits where appropriate.
* Such entries to the ChangeLog need not be full duplications of their
related commit logs if the latter are thorough explanations of
what's involved in the commit. In such cases it's perfectly
acceptable to enter just a summary of the commit and point the
reader to further information through the related git commit and
Trac ticket number (if applicable).
* Related commits to "base" should be grouped in a single ChangeLog
entry.
* Commits to "base" need not update the base/NEWS file, as such will be
constructed with the relevant information at MacPorts release time
by the release engineers.
# Whitespace rules as discussed on the development list (macports-dev):
* All source code files MUST use soft tabs at a tabstop of 4. No hard
tabs are allowed.
* All source code files SHOULD have the following as the first line of
the file:
# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
This is a modeline that works for both emacs and vim.
* Portfiles SHOULD use soft tabs at a tabstop of 4, but implementation
of this is left up to the discretion of the maintainer.
* Portfiles SHOULD use the given modeline
* Makefiles MUST use tabs as it is required by the syntax. Makefiles
SHOULD use a tab stop of 8.
* Makefiles MAY use a modeline. The following works for emacs and vim:
# -*- coding: utf-8; mode: Makefile; tab-width: 8; indent-tabs-mode: t -*- vim:fenc=utf-8:ft=Makefile:noet:sw=8:ts=8
* All other files (documentation, etc) SHOULD use soft tabs at a tabstop
of 4 if the document format allows.
* All other files (documentation, etc) SHOULD NOT use a modeline as it
is probably meant for human consumption.
# Documentation and Testing
* Additional documentation can be found in the MacPorts Guide:
https://guide.macports.org/#internals
* When adding new features, always add test cases.
https://guide.macports.org/#internals.tests