Two fixes
I pulled two commits out of !57 since it would be good to have them included, and specifically the `buildToolsVersion` issue was just discussed.
The current state of the `buildToolsVersion` replacement is not good. It will replace this:
```
buildToolsVersion '21.0.1'
```
with this:
```
buildToolsVersion = '21.0.1'
```
That is incorrect, since the first form is more like a function call than a variable assignment. So most likely that is causing the `buildToolsVersion` to be unset. The commit here includes a fix that works for both the rare, non-standard variable assignment way, i.e. `buildToolsVersion = '21.0.1'` as well as the standard way: `buildToolsVersion '21.0.1'`. It also includes tests for both cases.
See merge request !65
This addresses the discussion in !64https://gitlab.com/fdroid/fdroidserver/merge_requests/64
Sometimes, buildToolsVersion is a kind of gradle macro call, and other
times it is a variable assignment. This regsub pattern now handles both of
those cases.
Google code is dead and going read-only. import is just a helper program, and
we don't want to help people add apps from google code anymore. Apps should
move to other hosting sites.
Fix gradle adaptation for custom buildToolsVersion configurations
I have ```build_tools = "22.0.1"``` configured in my config.py, however a recent fdroidserver update broke this. This PR fixes it for me.
See merge request !64
final 0.4.0 fixes
Because `setup.py` is broken because `MANIFEST.in` is still pointing to `README` and not `README.md`, the 0.4.0 tag needs to be deleted. This merge requests fixes that and two other minor issues. This has passed multiple runs of the test suite, both on my machine and the jenkins box.
See merge request !61
let setuptools determine the base install path on OSX
This is the last commit from me before the 0.4.0 release. Its ready to go!
A gentle reminder:
* sign the tag: `git tag -s 0.4.0 -m "tagging release 0.4.0"`
* release tags are `0.4.0` format, not `v0.4.0`
* change the version in `setup.py` to match the tag exactly, char by char
Then I'll post the update to pypi.python.org
See merge request !59
Instead of trying to guess which absolute path and .egg name
everything will be installed into, just use a relative path and the
setup process will do the right thing (so far, at least).
