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