Hush Full Node software. We were censored from Github, this is where all development happens now. https://hush.is
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

97 lines
3.4 KiB

5 years ago
# Being a Hush Developer
## Compiling Hush
Normal compiling is as simple as:
4 years ago
./build.sh
5 years ago
To make it use as many CPU threads as you have:
4 years ago
./build.sh -j$(nproc) # assumes linux
./build.sh -j8 # use a fixed 8 threads, more portable
5 years ago
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
3 years ago
Let's say you change a dependency and want the compile to 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.
5 years ago
## Good Hygiene
4 years ago
To avoid weird build system issues, it's often good to run:
5 years ago
make clean
*before* you switch Git branches. Otherwise, the new branches Makefiles
often are incompatible and `make clean` will be impossible, which can
sometimes introduce weird bugs or make compiling really annoying.
4 years ago
If `make clean` produces a compilation error, you just experienced it.
5 years ago
## Switching branches
4 years ago
Switching branches and doing partial compiles in Hush source code
5 years ago
can introduce weird bugs, which are fixed by running `build.sh` again.
Additionally, it's a good idea to run `make clean` before you switch
between branches.
5 years ago
## Partial compiles
At any point, you can modify hush source code and then use `make` or `build.sh`
to do a partial compile. The first is faster but the latter is more likely to
work correctly in all circustances. Sometimes partial compiles break weird
build system dependencies, and you must do a `make clean` first, or even
`git clean -fdx` (look up what it means first!) to clean things. The nuclear
option is to re-clone the repo, which sometimes is the least work to fix
the problem.
4 years ago
Running `make` doesn't understand about dependency changes, such as Rust crates.
A simple C/C++ change can be tested with just `make` but if you change the version
of a dependency or something inside of Rust, you will need `build.sh` .
5 years ago
## Generating new unix man pages
Make sure that you have updated all version numbers in hushd and compiled, then
to generate new unix man pages for that version :
./util/gen-manpages.sh
5 years ago
## Generating new debian packages
After successfully compiling Hush, you can generate a debian package of these binaries with:
./util/build-debian-package.sh
5 years ago
4 years ago
This command will not work on Mac OS X. Currently you cannot generate a Debian package
from operating systems other than Linux. Oh well.
## Updates to this document
If you think something else should be in this guide, please send your suggestions!
4 years ago
Gitea: https://git.hush.is/hush/hush3