|
|
@ -11,6 +11,36 @@ To make it use as many CPU threads as you have: |
|
|
|
./build.sh -j$(nproc) # assumes linux |
|
|
|
./build.sh -j8 # use a fixed 8 threads, more portable |
|
|
|
|
|
|
|
This is dangerous! You need about 2GB of RAM per thread, plus all the |
|
|
|
other programs and Operating System overhead. A good rule of thumb is: |
|
|
|
|
|
|
|
Divide how many GBs of RAM you have by 2, subtract one. Use that many jobs. |
|
|
|
|
|
|
|
|
|
|
|
## Dealing with dependency changes |
|
|
|
|
|
|
|
Let's say you change a dependency and want the compile the notice. If your |
|
|
|
change is outside of the main Hush source code, in ./src, simply running |
|
|
|
`make` will not notice, and sometimes not even `build.sh`. You can always |
|
|
|
do a fresh clone or `make clean`, but that will take a lot of time. Those |
|
|
|
methods are actually best for Continuous Integration systems, but to help |
|
|
|
reduce the time a developer has to wait, here are some PROTIPs. |
|
|
|
|
|
|
|
|
|
|
|
If you are changing how a dependency is built, you should remove the entire directory like this: |
|
|
|
|
|
|
|
rm -rf depends/work/build/x86_64-unknown-linux-gnu/wolfssl/ |
|
|
|
|
|
|
|
The above will delete the entire source code of wolfssl dependency on `x86_64` |
|
|
|
but it will keep the tar.gz and you will not need to download it again. If |
|
|
|
you are testing a change in URL or SHA256, you will want to force it to download |
|
|
|
again: |
|
|
|
|
|
|
|
rm -rf depends/sources/wolfssl*.tar.gz |
|
|
|
|
|
|
|
Now when you run `build.sh` again, you will be able to test your changes. |
|
|
|
|
|
|
|
|
|
|
|
## Good Hygiene |
|
|
|
|
|
|
|
To avoid weird build system issues, it's often good to run: |
|
|
|