From d6b850a8551361634483a9b3b620b183d110fd15 Mon Sep 17 00:00:00 2001 From: Duke Leto Date: Sun, 24 Jan 2021 11:15:50 -0500 Subject: [PATCH] Add protipz for hushdevz --- DEVELOPING.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/DEVELOPING.md b/DEVELOPING.md index b686910aa..0a10da9f6 100644 --- a/DEVELOPING.md +++ b/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: