You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.rst
+63-17Lines changed: 63 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ Thanks for your interest in contributing to cpplint.
6
6
Any kinds of contributions are welcome: Bug reports, Documentation, Patches.
7
7
8
8
However cpplint is a bit special as a project because it aims to closely follow what Google does in the upstream repository.
9
-
That means Google remains the source of all major requirements and functinoality of cpplint, where as this fork adds extensions to cpplint run on more environments and in more companies.
9
+
That means Google remains the source of all major requirements and functionality of cpplint, where as this fork adds extensions to cpplint run on more environments and in more companies.
10
10
The difference between this cpplint and Google should remain so small that anyone can at a glance see there is no added change that could be regarded as a security vulnerability.
11
11
12
12
Here are some tips to make best use of your time:
@@ -29,40 +29,77 @@ Non-Goals:
29
29
Development
30
30
-----------
31
31
32
+
For many tasks, it is okay to just develop using a single installed python version. But if you need to test/debug the project in multiple python versions, you need to install those versions::
33
+
34
+
1. (Optional) Install multiple python versions
35
+
36
+
1. (Optional) Install [pyenv](https://github.com/pyenv/pyenv-installer) to manage python versions
37
+
2. (Optional) Using pyenv, install the python versions used in testing::
38
+
39
+
pyenv install 2.7.16
40
+
pyenv install 3.6.8
41
+
# ...
42
+
pyenv local 2.7.16 3.6.8 ...
43
+
44
+
It may be okay to run and test python against locally installed libraries, but if you need to have a consistent build, it is recommended to manage your environment using virtualenv: [virtualenv](https://virtualenv.pypa.io/en/latest/ ), [virtualenvwrapper](https://pypi.org/project/virtualenvwrapper/ ):
45
+
46
+
1. (Optional) Setup a local virtual environment with all necessary tools and libraries::
47
+
48
+
mkvirtualenv cpplint [-p /usr/bin/python3]
49
+
pip install .[dev]
50
+
51
+
Alternatively you can locally install patches like this::
52
+
53
+
pip install -e .[dev]
54
+
# for usage without virtualenv, add --user
55
+
32
56
You can setup your local environment for developing patches for cpplint like this:
./tox # all of the above in all python environments
68
+
./flake8
69
+
tox # all of the above in all python environments
42
70
43
71
Releasing
44
72
---------
45
73
74
+
The release process first prepares the documentation, then publishes to testpypi to verify, then releases to real pypi. Testpypi acts like real pypi, so broken releases cannot be deleted. For a typical bugfixing release, no special issue on testpypi is expected (but it's still good practice).
75
+
46
76
To release a new version:
47
77
48
78
.. code-block:: bash
49
79
50
-
vi setup.py # increment the version
80
+
# prepare files for release
81
+
vi cpplint.py # increment the version
51
82
vi changelog.rst # log changes
52
-
git add setup.py changelog.rst
53
-
git commit -m "Releasing 0.0.6"
54
-
git tag 0.0.6
55
-
git push
56
-
git push --tags
57
-
pip install --upgrade setuptools wheels twine
83
+
git add cpplint.py changelog.rst
84
+
git commit -m "Releasing x.y.z"
85
+
# test-release (on env by mkvirtualenv -p /usr/bin/python3)
86
+
pip install --upgrade setuptools wheel twine
87
+
rm -rf dist
88
+
# Test release, requires account on testpypi
58
89
python3 setup.py sdist bdist_wheel
59
-
twine upload dist/*
90
+
twine upload --repository testpypi dist/*
91
+
# ... Check website and downloads from https://test.pypi.org/project/cpplint/
92
+
# Actual release
93
+
twine upload dist/*
94
+
git tag x.y.z
95
+
git push --tags
60
96
97
+
After releasing, it is be good practice to comment on github for closed tickets, to notify authors.
61
98
62
99
Catching up with Upstream
63
100
-------------------------
64
101
65
-
For maintainers, it is a regular duty to look at what cpplint changes were merged upstream, to include them in this fork.
102
+
For maintainers, it is a regular duty to look at what cpplint changes were merged upstream, to include them in this fork (though these updates happen once per year and less).
66
103
67
104
Checkout here and upstream google:
68
105
@@ -77,13 +114,22 @@ To incorporate google's changes:
77
114
.. code-block:: bash
78
115
79
116
git fetch google gh-pages
117
+
118
+
## Merge workflow (clean, no new commits)
119
+
git checkout master -b updates
120
+
git merge google/gh-pages # this will have a lot of conflicts
121
+
# ... solve conflicts
122
+
git merge -- continue
123
+
124
+
## Rebase workflow (dirty, creates new commits)
80
125
git checkout -b updates FETCH_HEAD
81
126
git rebase master # this will have a lot of conflicts, most of which can be solved with the next command (run repeatedly)
82
127
# solve conflicts with files deleted in our fork (this is idempotent and safe to be called. when cpplint.py has conflicts, it will do nothing)
83
-
git status | grep 'new file:'| awk '{print $3}'| xargs -r git rm --cached ; git status | grep 'deleted by us'| awk '{print $4}'| xargs -r git rm ; git status --untracked-files=no | grep 'nothing to commit'&& git rebase --skip
128
+
git status | grep 'new file:'| awk '{print $3}'| xargs -r git rm --cached ; git status | grep 'deleted by us'| awk '{print $4}'| xargs -r git rm
129
+
git status --untracked-files=no | grep 'nothing to commit'&& git rebase --skip
84
130
85
131
git push -u origin updates
86
-
# check travis
132
+
# check github action
87
133
git push origin --delete updates
88
134
89
135
git rebase updates master
@@ -103,7 +149,7 @@ Setup fetching of pull requests in .git/config:
103
149
url = https://github.com/google/styleguide
104
150
fetch = +refs/heads/*:refs/remotes/google/*
105
151
# following line should be new, fetches PRs from google/styleguides
@@ -26,9 +23,10 @@ cpplint - static code checker for C++
26
23
:target:https://pypi.python.org/pypi/cpplint
27
24
28
25
Cpplint is a command-line tool to check C/C++ files for style issues following `Google's C++ style guide <http://google.github.io/styleguide/cppguide.html>`_.
29
-
Cpplint is developed and maintained by Google Inc. at `google/styleguide <https://github.com/google/styleguide>`_, also see see the `wikipedia entry <http://en.wikipedia.org/wiki/Cpplint>`_
26
+
Cpplint is developed and maintained by Google Inc. at `google/styleguide <https://github.com/google/styleguide>`_, also see the `wikipedia entry <http://en.wikipedia.org/wiki/Cpplint>`_
30
27
31
28
While Google maintains cpplint, Google is not (very) responsive to issues and pull requests, this fork aims to be (somewhat) more open to add fixes to cpplint to enable fixes, when those fixes make cpplint usable in wider contexts.
29
+
Also see discussion here https://github.com/google/styleguide/pull/528.
32
30
33
31
34
32
Installation
@@ -56,17 +54,18 @@ For full usage instructions, run:
56
54
Changes
57
55
-------
58
56
59
-
The modifications in this fork are minor fixes and cosmetic changes:
57
+
The modifications in this fork are minor fixes and cosmetic changes, such as:
60
58
61
-
* more default extensions
62
59
* python 3 compatibility
60
+
* more default file extensions
63
61
* customizable file extensions with the --extensions argument
64
-
* continuous integration on travis
62
+
* continuous integration on github
65
63
* support for recursive file discovery via the --recursive argument
66
64
* support for excluding files via --exclude
67
65
* JUnit XML output format
68
66
* Overriding repository root auto-detection via --repository
69
67
* Support ``#pragma once`` as an alternative to header include guards
68
+
* ... and a few more (most of which are open PRs on upstream)
0 commit comments