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
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
|
Build from repository
---------------------
``` shell
$ ./bootstrap
$ ./configure
```
The bootstrap script will use autotools to set up the build environment
and create the `configure` script.
Use `./configure --help` for options. Use `--prefix` to make an install in
your home directory. This is necessary to test python scripts. The systemd
user unit directory should be set to avoid writing to the system location.
Systemd will look for the unit files in `~/.config/systemd/user` so this
directory can be used as a target if the unit files will be used. Otherwise
the location can be set to `no` to disable the systemd files.
Example:
``` shell
$ ./configure --prefix=$HOME/redshift/root \
--with-systemduserunitdir=$HOME/.config/systemd/user
```
Now, build the files:
``` shell
$ make
```
The main redshift program can be run at this point. To install to the
prefix directory run:
``` shell
$ make install
```
You can now run the python script. Example:
``` shell
$ $HOME/redshift/root/bin/redshift-gtk
```
Dependencies
------------
* autotools, gettext
* intltool
* libdrm (Optional, for DRM support)
* libxcb, libxcb-randr (Optional, for RandR support)
* libX11, libXxf86vm (Optional, for VidMode support)
* geoclue (Optional, for geoclue support)
* python3, pygobject, pyxdg (Optional, for GUI support)
* appindicator (Optional, for Ubuntu-style GUI status icon)
Ubuntu users will find all these dependencies in the packages listed in ``.travis.yml``.
Coding style
------------
Redshift follows roughly the Linux coding style
<http://www.kernel.org/doc/Documentation/CodingStyle>. Some specific rules to
note are:
* Lines should not be much longer than 80 chars but this is not strictly
enforced. If lines are much longer than this the code could likely be improved
by moving some parts to a smaller function.
* All structures are typedef'ed.
* Avoid Yoda conditions; they make the logic unnecessarily hard to comprehend.
* Avoid multiline if-statements without braces; either use a single line or add
the braces.
* Use only C-style comments (`/* */`).
Creating a pull request
-----------------------
1. Create a topic branch for your specific changes. You can base this off the
master branch or a specific version tag if you prefer (`git co -b topic master`).
2. Create a commit for each logical change on the topic branch. The commit log
must contain a one line description (max 80 chars). If you cannot describe
the commit in 80 characters you should probably split it up into multiple
commits. The first line can be followed by a blank line and a longer
description (split lines at 80 chars) for more complex commits. If the commit
fixes a known issue, mention the issue number in the first line (`Fix #11:
...`).
3. The topic branch itself should tackle one problem. Feel free to create many
topic branches and pull requests if you have many different patches. Putting
them into one branch makes it harder to review the code.
4. Push the topic branch to Github, find it on github.com and create a pull
request to the master branch. If you are making a bug fix for a specific
release you can create a pull request to the release branch instead
(e.g. `release-1.9`).
5. Discussion will ensue. If you are not prepared to partake in the discussion
or further improve your patch for inclusion, please say so and someone else
may be able to take on responsibility for your patch. Otherwise we will
assume that you will be open to critisism and suggestions for improvements
and that you will take responsibility for further improving the patch. You
can add further commits to your topic branch and they will automatically be
added to the pull request when you push them to Github.
6. You may be asked to rebase the patch on the master branch if your patch
conflicts with recent changes to the master branch. However, if there is no
conflict, there is no reason to rebase. Please do not merge the master back
into your topic branch as that will convolute the history unnecessarily.
7. Finally, when your patch has been refined, you may be asked to squash small
commits into larger commits. This is simply so that the project history is
clean and easy to follow. Remember that each commit should be able to stand
on its own, be able to compile and function normally. Commits that fix a
small error or adds a few comments to a previous commit should normally just
be squashed into that larger commit.
If you want to learn more about the Git branching model that we use please see
<http://nvie.com/posts/a-successful-git-branching-model/> but note that we use
the `master` branch as `develop`.
Creating a new release
----------------------
1. Select a commit in master to branch from, or if making a bugfix release
use previous release tag as base (e.g. for 1.9.1 use 1.9 as base)
2. Create release branch `release-X.Y`
3. Apply any bugfixes for release
4. Import updated translations from launchpad and commit. Remember to update
`po/LINGUAS` if new languages were added
5. Update version in `configure.ac` and create entry in NEWS
6. Run `make distcheck`
7. Commit and tag release (`vX.Y` or `vX.Y.Z`)
8. Push tag to Github and also upload source dist file to Github
Also remember to check before release that
* Windows build is ok
* Build files for distributions are updated
Build Fedora RPMs
-----------------
Run `make dist-xz` and copy the `.tar.xz` file to `~/rpmbuild/SOURCES`. Then run
``` shell
$ rpmbuild -ba contrib/redshift.spec
```
If successful this will place RPMs in `~/rpmbuild/RPMS`.
Cross-compile for Windows
-------------------------
Install MinGW and run `configure` using the following command line. Use
`i686-w64-migw32` as host for 32-bit builds.
``` shell
$ ./configure --disable-drm --disable-randr --disable-vidmode --enable-wingdi \
--disable-geoclue --disable-gui --disable-ubuntu \
--host=x86_64-w64-mingw32
```
Notes
-----
* verbose flag is (currently) only held in redshift.c; thus, write all
verbose messages there.
|