Browse Source

Add protipz for hushdevz

pull/32/head
Duke Leto 3 years ago
parent
commit
d6b850a855
  1. 30
      DEVELOPING.md

30
DEVELOPING.md

@ -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:

Loading…
Cancel
Save