Merge pull request #85 from zcash/update-troubleshooting
Update troubleshooting
This commit is contained in:
commit
099786fbd1
33
README.md
33
README.md
|
@ -169,12 +169,32 @@ We don't like reinveing the wheel, so be gently borrowed swift lint rules from A
|
||||||
|
|
||||||
## Troubleshooting
|
## Troubleshooting
|
||||||
|
|
||||||
#### No network environment....
|
### No network environment....
|
||||||
if you see this message when building:
|
if you see this message when building:
|
||||||
```No network environment. Set ZCASH_NETWORK_ENVIRONMENT to MAINNET or TESTNET```
|
```No network environment. Set ZCASH_NETWORK_ENVIRONMENT to MAINNET or TESTNET```
|
||||||
make sure your dev environment is has this variable set before the build starts. *DO NOT CHANGE IT DURING THE BUILD PROCESS*.
|
make sure your dev environment is has this variable set before the build starts. *DO NOT CHANGE IT DURING THE BUILD PROCESS*.
|
||||||
|
|
||||||
#### _function_name referenced from...
|
If the variable was properly set *after* you've seen this message, you will need to either a) set it manually on the pod's target or b) doing a clean pod install and subsequent build.
|
||||||
|
|
||||||
|
#### a) setting the flag manually
|
||||||
|
1. on your workspace, select the Pods project.
|
||||||
|
2. on the Targets pane, select ZcashLightClientKit
|
||||||
|
3. go to build settings
|
||||||
|
4. scroll down to see ZCASH_NETWORK_ENVIRONMENT and complete with TESTNET or MAINNET
|
||||||
|
|
||||||
|
![how to complete network environtment manually](docs/images/complete_environment_manually.png)
|
||||||
|
|
||||||
|
#### b) clean pod install
|
||||||
|
it's not necessary to delete the whole Pods/ directory and download all of your dependencies again.
|
||||||
|
1. on your project root, locate the `Pods/` directory
|
||||||
|
2. remove ZcashLightClientKit from it
|
||||||
|
3. clean derived data from xcode
|
||||||
|
4. close xcode
|
||||||
|
5. run `pod install` (run --verbose to see more details)
|
||||||
|
6. open xcode project
|
||||||
|
7. build
|
||||||
|
|
||||||
|
### _function_name referenced from...
|
||||||
if you get a build error similar to ```_function_name referenced from...```
|
if you get a build error similar to ```_function_name referenced from...```
|
||||||
|
|
||||||
* on your project root directory *
|
* on your project root directory *
|
||||||
|
@ -183,6 +203,15 @@ if you get a build error similar to ```_function_name referenced from...```
|
||||||
3. run `pod install`
|
3. run `pod install`
|
||||||
4. build
|
4. build
|
||||||
|
|
||||||
|
### ZcashLightClientKitSample missing .params
|
||||||
|
ZcashLightClientKit has an external dependency on 2 files containing Sapling parameters. Although you can provide those files as you seem fit, the sample app requires them on the main bundle.
|
||||||
|
|
||||||
|
You can download these files from https://z.cash/downloads/sapling-spend.params
|
||||||
|
and https://z.cash/downloads/sapling-output.params and then move them to the correct folder, which is specified on the error itself.
|
||||||
|
|
||||||
|
![how to fix missing params files](docs/images/output_params_error.png)
|
||||||
|
|
||||||
|
|
||||||
## Versioning
|
## Versioning
|
||||||
|
|
||||||
This project follows [semantic versioning](https://semver.org/) with pre-release versions. An example of a valid version number is `1.0.4-alpha11` denoting the `11th` iteration of the `alpha` pre-release of version `1.0.4`. Stable releases, such as `1.0.4` will not contain any pre-release identifiers. Pre-releases include the following, in order of stability: `alpha`, `beta`, `rc`. Version codes offer a numeric representation of the build name that always increases. The first six significant digits represent the major, minor and patch number (two digits each) and the last 3 significant digits represent the pre-release identifier. The first digit of the identifier signals the build type. Lastly, each new build has a higher version code than all previous builds. The following table breaks this down:
|
This project follows [semantic versioning](https://semver.org/) with pre-release versions. An example of a valid version number is `1.0.4-alpha11` denoting the `11th` iteration of the `alpha` pre-release of version `1.0.4`. Stable releases, such as `1.0.4` will not contain any pre-release identifiers. Pre-releases include the following, in order of stability: `alpha`, `beta`, `rc`. Version codes offer a numeric representation of the build name that always increases. The first six significant digits represent the major, minor and patch number (two digits each) and the last 3 significant digits represent the pre-release identifier. The first digit of the identifier signals the build type. Lastly, each new build has a higher version code than all previous builds. The following table breaks this down:
|
||||||
|
|
Binary file not shown.
After Width: | Height: | Size: 370 KiB |
Binary file not shown.
After Width: | Height: | Size: 287 KiB |
Loading…
Reference in New Issue