mirrors/bisq
1
0
Fork 0
mirror of https://github.com/bisq-network/bisq.git synced 2024-11-19 01:41:11 +01:00
Code Issues Packages Projects Releases Wiki Activity
baa2f2bd9b
bisq/Makefile

265 lines
7.8 KiB
Makefile
Raw Normal View History

Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
#
# INTRODUCTION
#
# This makefile is designed to help Bisq contributors get up and running
# as quickly as possible with a local regtest Bisq network deployment,
# or 'localnet' for short. A localnet is a complete and self-contained
# "mini Bisq network" suitable for development and end-to-end testing
# efforts.
#
#
# REQUIREMENTS
#
# You'll need the following to proceed:
#
# - Linux, macOS or similar *nix with standard tools like `make`
# - bitcoind and bitcoin-cli (`brew install bitcoin` on macOS)
# - JDK 10 to build and run Bisq binaries; see
# https://www.oracle.com/java/technologies/java-archive-javase10-downloads.html
#
#
# USAGE
#
Update .editorconfig to use hard tabs in Makefile Problem: we use soft 4-space tabs throughout the Bisq codebase, and the new makefile is a break to this rule due to make's default requirement for hard tabs in recipes. Solution: This commit updates our Editorconfig settings to reflect this exception. For vim users, it is also recommended that you add the following entry to your .vimrc: au FileType make set tw=72 noet cc=72 It will ensure that you wrap (documentation) lines at 72 chars. It also sets noexpandtab explicitly. Even though .editorconfig should already be doing this for you when working in Bisq, this more general vim configuration will ensure you use tabs correctly in any makefile. The `cc=72` setting adds a visual right margin at 72 characters. This commit also updates the existing makefile, wrapping lines of documentation that had exceeded the 72-char margin.
2019-12-02 17:52:28 +01:00
# The following commands (and a couple manual instructions) will get
# your localnet up and running quickly.
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
#
Update .editorconfig to use hard tabs in Makefile Problem: we use soft 4-space tabs throughout the Bisq codebase, and the new makefile is a break to this rule due to make's default requirement for hard tabs in recipes. Solution: This commit updates our Editorconfig settings to reflect this exception. For vim users, it is also recommended that you add the following entry to your .vimrc: au FileType make set tw=72 noet cc=72 It will ensure that you wrap (documentation) lines at 72 chars. It also sets noexpandtab explicitly. Even though .editorconfig should already be doing this for you when working in Bisq, this more general vim configuration will ensure you use tabs correctly in any makefile. The `cc=72` setting adds a visual right margin at 72 characters. This commit also updates the existing makefile, wrapping lines of documentation that had exceeded the 72-char margin.
2019-12-02 17:52:28 +01:00
# STEP 1: Build all Bisq binaries and set up localnet resources. This
# will take a few minutes the first time through.
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
#
# $ make
#
# Notes:
#
# - When complete, you'll have a number of scripts available in the
# root directory. They will be used in the make targets below to start
# the various Bisq seed and desktop nodes that will make up your
# localnet:
#
# $ ls -1 bisq-*
# bisq-desktop
# bisq-monitor
# bisq-pricenode
# bisq-relay
# bisq-seednode
# bisq-statsnode
#
Use STATE_DIR := .localnet in makefile
2019-11-30 07:50:59 +01:00
# - You will see a new '.localnet' directory containing the data dirs
Update .editorconfig to use hard tabs in Makefile Problem: we use soft 4-space tabs throughout the Bisq codebase, and the new makefile is a break to this rule due to make's default requirement for hard tabs in recipes. Solution: This commit updates our Editorconfig settings to reflect this exception. For vim users, it is also recommended that you add the following entry to your .vimrc: au FileType make set tw=72 noet cc=72 It will ensure that you wrap (documentation) lines at 72 chars. It also sets noexpandtab explicitly. Even though .editorconfig should already be doing this for you when working in Bisq, this more general vim configuration will ensure you use tabs correctly in any makefile. The `cc=72` setting adds a visual right margin at 72 characters. This commit also updates the existing makefile, wrapping lines of documentation that had exceeded the 72-char margin.
2019-12-02 17:52:28 +01:00
# for your regtest Bitcoin and Bisq nodes. Once you've deployed them in
# the step below, the directory will look as follows:
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
#
Use STATE_DIR := .localnet in makefile
2019-11-30 07:50:59 +01:00
# $ tree -d -L 1 .localnet
# .localnet
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
# ├── alice
# ├── bitcoind
# ├── bob
# ├── mediator
# ├── seednode
# └── seednode2
#
# STEP 2: Deploy the Bitcoin and Bisq nodes that make up the localnet.
# Run each of the following in a SEPARATE TERMINAL WINDOW, as they are
# long-running processes.
#
# $ make bitcoind
# $ make seednode
# $ make seednode2
# $ make mediator
# $ make alice
# $ make bob
#
# Tip: Those familiar with the `screen` terminal multiplexer can
# automate the above by running the `deploy` target found below.
#
# Notes:
#
# - The 'seednode' targets launch headless Bisq nodes that help
# desktop nodes discover other peers, as well as storing and
# forwarding p2p network messages for nodes as they go on and
# offline.
#
# - As you run the 'mediator', 'alice' and 'bob' targets above,
# you'll see a Bisq desktop node window appear for each. The Alice
# and Bob instances represent two traders who can make and take
# offers with one another. The Mediator instance represents a Bisq
# contributor who can help resolve any technical problems or disputes
# that come up between the two traders.
#
# STEP 3: Configure the mediator Bisq node. In order to make and take
# offers, Alice and Bob will need to have a mediator and a refund agent
# registered on the network. Follow the instructions below to complete
# that process:
#
Update commands for mediator/refund agent Commands are flipped in the documentation. CMD+D for Mediator CMD+N for Refund Agent
2021-03-17 08:26:25 +01:00
# a) Go to the Account screen in the Mediator instance and press CMD+D
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
# and a popup will appear. Click 'Unlock' and then click 'Register' to
# register the instance as a mediator.
#
Update commands for mediator/refund agent Commands are flipped in the documentation. CMD+D for Mediator CMD+N for Refund Agent
2021-03-17 08:26:25 +01:00
# b) While still in the Account screen, press CMD+N and follow the same
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
# steps as above to register the instance as a refund agent.
#
# When the steps above are complete, your localnet should be up and
# ready to use. You can now test in isolation all Bisq features and use
# cases.
#
# Set up everything necessary for deploying your localnet. This is the
# default target.
Review "Use STATE_DIR := .localnet in makefile" This change follows up on commit 650c5894d, which: 1. Renamed the 'localdir' directory to '.localdir' to better follow convention with how local data directories are often managed, e.g. .git and .gradle. 2. Introduced the STATE_DIR variable to avoid duplication of the '.localdir' string throughout the Makefile, and at least in concept to allow this value to be customized via setting an environment variable. The changes in (1) are preserved, while the changes in (2) have been backed out. Rationale: - The STATE_DIR name introduces a new concept to the reader. They must reason about its meaning, and this works against the intention of the Makefile, which is to maximize understandability for the uninitiated. - The name, if we were to preserve the variable, probably should have been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually incorrect, but industry convention is to refer to such directories as "data directories", e.g. Bitcoin Core's `datadir` option, LND's `datadir` option and Bisq's `userDataDir` and `appDataDir` options. - The variable, whatever its name, introduces a layer of indirection, which while convenient to the makefile maintainer, is a barrier to comprehension for the reader / contributor. For example, if a user wished to copy and paste the recipe for a target, say 'bob' from the makefile, with the varible in place, the user would have to figure out its correct value and replace it before they could paste and use the copied command. Like in the first note above, the idea with the makefile is to maximize understanding for the uninitiated, i.e. working code as executable documentation. It is reasonable given this goal to increase the burden on a few maintainers in order to ease the potentially many contributors. Finally, this change follows up on the renaming of the 'localnet' directory to '.localnet' by reflecting this change in the name of the associated target as well. This is order to avoid dependent targets e.g. 'bitcoind', 'alice' or 'bob' constantly re-running the localnet target. In turn it also adds an 'alias' target named 'localnet' (without the leading dot) because targets with a leading dot are (I believe) treated as "implicit targets". In any case, they do not show up in a tab completion context, so introducing the normally-named alias fixes that. This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
setup: build .localnet
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
clean: clean-build clean-localnet
clean-build:
Make 'build' target phony once again In commit 5fb4b21 ("Refine deploy target..."), the 'build' target was made normal, i.e. non-phony, but on further review it does in fact make sense to declare 'build' phony, such that it is run no matter the status of the root-level 'build' directory, but for different reasons. Previously, we had been considering the presence of 'build' directory as a reasonable proxy for determining whether the `./gradlew build` had been run. If the directory was present, we considered the 'build' target up-to-date. If not, then we would re-run `./gradlew build`. This is all sensible enough, except for the fact that the root-level 'build' directory has almost nothing to do with the actual output of `./gradlew build`. Gradle does output 'build' directories, but in the respective subdirectory for each module of the project. After `./gradlew build` has been run, we would see a 'desktop/build' directory, a 'seednode/build' directory and so forth. It just so happens that a root-level 'build' directory was getting created at all due to idiosyncracies of a particular Kotlin plugin. This commit updates the makefile to better respect this reality by: - preserving the 'build' target but marking it once again as PHONY - introducing new 'seednode/build' and 'desktop/build' targets that trigger './gradlew :seednode:build` and ./gradlew :desktop:build` commands respectively. - making 'build' depend on these two new targets In light of this realization of flawed thinking about the root-level build dir, this change also restores `make clean` to calling `./gradlew clean` instead of `rm -rf build`.
2019-12-02 21:25:59 +01:00
./gradlew clean
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
clean-localnet:
Review "Use STATE_DIR := .localnet in makefile" This change follows up on commit 650c5894d, which: 1. Renamed the 'localdir' directory to '.localdir' to better follow convention with how local data directories are often managed, e.g. .git and .gradle. 2. Introduced the STATE_DIR variable to avoid duplication of the '.localdir' string throughout the Makefile, and at least in concept to allow this value to be customized via setting an environment variable. The changes in (1) are preserved, while the changes in (2) have been backed out. Rationale: - The STATE_DIR name introduces a new concept to the reader. They must reason about its meaning, and this works against the intention of the Makefile, which is to maximize understandability for the uninitiated. - The name, if we were to preserve the variable, probably should have been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually incorrect, but industry convention is to refer to such directories as "data directories", e.g. Bitcoin Core's `datadir` option, LND's `datadir` option and Bisq's `userDataDir` and `appDataDir` options. - The variable, whatever its name, introduces a layer of indirection, which while convenient to the makefile maintainer, is a barrier to comprehension for the reader / contributor. For example, if a user wished to copy and paste the recipe for a target, say 'bob' from the makefile, with the varible in place, the user would have to figure out its correct value and replace it before they could paste and use the copied command. Like in the first note above, the idea with the makefile is to maximize understanding for the uninitiated, i.e. working code as executable documentation. It is reasonable given this goal to increase the burden on a few maintainers in order to ease the potentially many contributors. Finally, this change follows up on the renaming of the 'localnet' directory to '.localnet' by reflecting this change in the name of the associated target as well. This is order to avoid dependent targets e.g. 'bitcoind', 'alice' or 'bob' constantly re-running the localnet target. In turn it also adds an 'alias' target named 'localnet' (without the leading dot) because targets with a leading dot are (I believe) treated as "implicit targets". In any case, they do not show up in a tab completion context, so introducing the normally-named alias fixes that. This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
rm -rf .localnet ./dao-setup
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
Make 'build' target phony once again In commit 5fb4b21 ("Refine deploy target..."), the 'build' target was made normal, i.e. non-phony, but on further review it does in fact make sense to declare 'build' phony, such that it is run no matter the status of the root-level 'build' directory, but for different reasons. Previously, we had been considering the presence of 'build' directory as a reasonable proxy for determining whether the `./gradlew build` had been run. If the directory was present, we considered the 'build' target up-to-date. If not, then we would re-run `./gradlew build`. This is all sensible enough, except for the fact that the root-level 'build' directory has almost nothing to do with the actual output of `./gradlew build`. Gradle does output 'build' directories, but in the respective subdirectory for each module of the project. After `./gradlew build` has been run, we would see a 'desktop/build' directory, a 'seednode/build' directory and so forth. It just so happens that a root-level 'build' directory was getting created at all due to idiosyncracies of a particular Kotlin plugin. This commit updates the makefile to better respect this reality by: - preserving the 'build' target but marking it once again as PHONY - introducing new 'seednode/build' and 'desktop/build' targets that trigger './gradlew :seednode:build` and ./gradlew :desktop:build` commands respectively. - making 'build' depend on these two new targets In light of this realization of flawed thinking about the root-level build dir, this change also restores `make clean` to calling `./gradlew clean` instead of `rm -rf build`.
2019-12-02 21:25:59 +01:00
# Build Bisq binaries and shell scripts used in the targets below
build: seednode/build desktop/build
seednode/build:
./gradlew :seednode:build
desktop/build:
./gradlew :desktop:build
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
# Unpack and customize a Bitcoin regtest node and Alice and Bob Bisq
# nodes that have been preconfigured with a blockchain containing the
# BSQ genesis transaction
Review "Use STATE_DIR := .localnet in makefile" This change follows up on commit 650c5894d, which: 1. Renamed the 'localdir' directory to '.localdir' to better follow convention with how local data directories are often managed, e.g. .git and .gradle. 2. Introduced the STATE_DIR variable to avoid duplication of the '.localdir' string throughout the Makefile, and at least in concept to allow this value to be customized via setting an environment variable. The changes in (1) are preserved, while the changes in (2) have been backed out. Rationale: - The STATE_DIR name introduces a new concept to the reader. They must reason about its meaning, and this works against the intention of the Makefile, which is to maximize understandability for the uninitiated. - The name, if we were to preserve the variable, probably should have been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually incorrect, but industry convention is to refer to such directories as "data directories", e.g. Bitcoin Core's `datadir` option, LND's `datadir` option and Bisq's `userDataDir` and `appDataDir` options. - The variable, whatever its name, introduces a layer of indirection, which while convenient to the makefile maintainer, is a barrier to comprehension for the reader / contributor. For example, if a user wished to copy and paste the recipe for a target, say 'bob' from the makefile, with the varible in place, the user would have to figure out its correct value and replace it before they could paste and use the copied command. Like in the first note above, the idea with the makefile is to maximize understanding for the uninitiated, i.e. working code as executable documentation. It is reasonable given this goal to increase the burden on a few maintainers in order to ease the potentially many contributors. Finally, this change follows up on the renaming of the 'localnet' directory to '.localnet' by reflecting this change in the name of the associated target as well. This is order to avoid dependent targets e.g. 'bitcoind', 'alice' or 'bob' constantly re-running the localnet target. In turn it also adds an 'alias' target named 'localnet' (without the leading dot) because targets with a leading dot are (I believe) treated as "implicit targets". In any case, they do not show up in a tab completion context, so introducing the normally-named alias fixes that. This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
.localnet:
Update .editorconfig to use hard tabs in Makefile Problem: we use soft 4-space tabs throughout the Bisq codebase, and the new makefile is a break to this rule due to make's default requirement for hard tabs in recipes. Solution: This commit updates our Editorconfig settings to reflect this exception. For vim users, it is also recommended that you add the following entry to your .vimrc: au FileType make set tw=72 noet cc=72 It will ensure that you wrap (documentation) lines at 72 chars. It also sets noexpandtab explicitly. Even though .editorconfig should already be doing this for you when working in Bisq, this more general vim configuration will ensure you use tabs correctly in any makefile. The `cc=72` setting adds a visual right margin at 72 characters. This commit also updates the existing makefile, wrapping lines of documentation that had exceeded the 72-char margin.
2019-12-02 17:52:28 +01:00
# Unpack the old dao-setup.zip and move things around for more
# concise and intuitive naming. This is a temporary measure until we
# clean these resources up more thoroughly.
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
unzip docs/dao-setup.zip
Review "Use STATE_DIR := .localnet in makefile" This change follows up on commit 650c5894d, which: 1. Renamed the 'localdir' directory to '.localdir' to better follow convention with how local data directories are often managed, e.g. .git and .gradle. 2. Introduced the STATE_DIR variable to avoid duplication of the '.localdir' string throughout the Makefile, and at least in concept to allow this value to be customized via setting an environment variable. The changes in (1) are preserved, while the changes in (2) have been backed out. Rationale: - The STATE_DIR name introduces a new concept to the reader. They must reason about its meaning, and this works against the intention of the Makefile, which is to maximize understandability for the uninitiated. - The name, if we were to preserve the variable, probably should have been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually incorrect, but industry convention is to refer to such directories as "data directories", e.g. Bitcoin Core's `datadir` option, LND's `datadir` option and Bisq's `userDataDir` and `appDataDir` options. - The variable, whatever its name, introduces a layer of indirection, which while convenient to the makefile maintainer, is a barrier to comprehension for the reader / contributor. For example, if a user wished to copy and paste the recipe for a target, say 'bob' from the makefile, with the varible in place, the user would have to figure out its correct value and replace it before they could paste and use the copied command. Like in the first note above, the idea with the makefile is to maximize understanding for the uninitiated, i.e. working code as executable documentation. It is reasonable given this goal to increase the burden on a few maintainers in order to ease the potentially many contributors. Finally, this change follows up on the renaming of the 'localnet' directory to '.localnet' by reflecting this change in the name of the associated target as well. This is order to avoid dependent targets e.g. 'bitcoind', 'alice' or 'bob' constantly re-running the localnet target. In turn it also adds an 'alias' target named 'localnet' (without the leading dot) because targets with a leading dot are (I believe) treated as "implicit targets". In any case, they do not show up in a tab completion context, so introducing the normally-named alias fixes that. This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
mv dao-setup .localnet
mv .localnet/Bitcoin-regtest .localnet/bitcoind
mv .localnet/bisq-BTC_REGTEST_Alice_dao .localnet/alice
mv .localnet/bisq-BTC_REGTEST_Bob_dao .localnet/bob
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
# Remove the preconfigured bitcoin.conf in favor of explicitly
# parameterizing the invocation of bitcoind in the target below
Review "Use STATE_DIR := .localnet in makefile" This change follows up on commit 650c5894d, which: 1. Renamed the 'localdir' directory to '.localdir' to better follow convention with how local data directories are often managed, e.g. .git and .gradle. 2. Introduced the STATE_DIR variable to avoid duplication of the '.localdir' string throughout the Makefile, and at least in concept to allow this value to be customized via setting an environment variable. The changes in (1) are preserved, while the changes in (2) have been backed out. Rationale: - The STATE_DIR name introduces a new concept to the reader. They must reason about its meaning, and this works against the intention of the Makefile, which is to maximize understandability for the uninitiated. - The name, if we were to preserve the variable, probably should have been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually incorrect, but industry convention is to refer to such directories as "data directories", e.g. Bitcoin Core's `datadir` option, LND's `datadir` option and Bisq's `userDataDir` and `appDataDir` options. - The variable, whatever its name, introduces a layer of indirection, which while convenient to the makefile maintainer, is a barrier to comprehension for the reader / contributor. For example, if a user wished to copy and paste the recipe for a target, say 'bob' from the makefile, with the varible in place, the user would have to figure out its correct value and replace it before they could paste and use the copied command. Like in the first note above, the idea with the makefile is to maximize understanding for the uninitiated, i.e. working code as executable documentation. It is reasonable given this goal to increase the burden on a few maintainers in order to ease the potentially many contributors. Finally, this change follows up on the renaming of the 'localnet' directory to '.localnet' by reflecting this change in the name of the associated target as well. This is order to avoid dependent targets e.g. 'bitcoind', 'alice' or 'bob' constantly re-running the localnet target. In turn it also adds an 'alias' target named 'localnet' (without the leading dot) because targets with a leading dot are (I believe) treated as "implicit targets". In any case, they do not show up in a tab completion context, so introducing the normally-named alias fixes that. This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
rm -v .localnet/bitcoind/bitcoin.conf
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
# Avoid spurious 'runCommand' errors in the bitcoind log when nc
# fails to bind to one of the listed block notification ports
Review "Use STATE_DIR := .localnet in makefile" This change follows up on commit 650c5894d, which: 1. Renamed the 'localdir' directory to '.localdir' to better follow convention with how local data directories are often managed, e.g. .git and .gradle. 2. Introduced the STATE_DIR variable to avoid duplication of the '.localdir' string throughout the Makefile, and at least in concept to allow this value to be customized via setting an environment variable. The changes in (1) are preserved, while the changes in (2) have been backed out. Rationale: - The STATE_DIR name introduces a new concept to the reader. They must reason about its meaning, and this works against the intention of the Makefile, which is to maximize understandability for the uninitiated. - The name, if we were to preserve the variable, probably should have been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually incorrect, but industry convention is to refer to such directories as "data directories", e.g. Bitcoin Core's `datadir` option, LND's `datadir` option and Bisq's `userDataDir` and `appDataDir` options. - The variable, whatever its name, introduces a layer of indirection, which while convenient to the makefile maintainer, is a barrier to comprehension for the reader / contributor. For example, if a user wished to copy and paste the recipe for a target, say 'bob' from the makefile, with the varible in place, the user would have to figure out its correct value and replace it before they could paste and use the copied command. Like in the first note above, the idea with the makefile is to maximize understanding for the uninitiated, i.e. working code as executable documentation. It is reasonable given this goal to increase the burden on a few maintainers in order to ease the potentially many contributors. Finally, this change follows up on the renaming of the 'localnet' directory to '.localnet' by reflecting this change in the name of the associated target as well. This is order to avoid dependent targets e.g. 'bitcoind', 'alice' or 'bob' constantly re-running the localnet target. In turn it also adds an 'alias' target named 'localnet' (without the leading dot) because targets with a leading dot are (I believe) treated as "implicit targets". In any case, they do not show up in a tab completion context, so introducing the normally-named alias fixes that. This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
echo exit 0 >> .localnet/bitcoind/blocknotify
# Alias '.localnet' to 'localnet' so the target is discoverable in tab
# completion
localnet: .localnet
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
# Deploy a complete localnet by running all required Bitcoin and Bisq
# nodes, each in their own named screen window. If you are not a screen
Refine deploy target for better use of `screen` Problem: Prior to this change, it was necessary to first create and attach to a screen session and then to run `make deploy` within it. This meant extra steps for the user and was generally error-prone. Solution: Usage of screen has been refined such that a screen session named 'localnet' is created on the users behalf without any need to attach to it. Individual node deployment targets such as `make bitcoind`, `make alice`, et al. are issued to new windows within the localnet screen session, and the user is free to attach or not whenever they choose. The result is that a new user can clone the repository and type nothing more than `make deploy` to get up and running with their localnet. This also reverts the changes in commit 97dd342e5 ("Make build target phony") for the following reasons: - As mentioned in that commit message, Gradle was not deleting the its 'build' directory when running `gradle clean`, meaning that the 'build' target was always up-to-date, even after running `make clean`. This made it impossible to get a correct rebuild workflow. On analysis, howewer, this situation was because of a badly behaving Kotlin plugin not cleaning up after itself, leaving a subdirectory at build/kotlin and preventing the build directory itself from being deleted altogether. To address this, the `make clean` target has been updated to `rm -rf build` instead of calling `build gradle`. While it's a workaround until we back out the Kotlin changes that caused this, it does have the added benefit of being faster than invoking `gradle clean`. - By making the 'build' target PHONY, this meant that `./gradlew build` was getting invoked every time a dependent target was called. For example, `make alice` depends on the 'setup' target, which in turn depends on the 'build' target. When calling such targets in isolation, this arrangement works out fine, because the phony 'build' target always runs, invoking `./gradle build`, and the Gradle build completes quickly assuming everything is up-to-date. The problem arises when calling a number of these targets in rapid succession, as we do when calling `make deploy` and running each individual node target in its own screen window. This causes contention in two ways. The first is that these multiple, simultaneous Gradle processes compete for access to an available Gradle daemon, and because each process needs its own, it ends up that as many Gradle daemons get created as Bisq nodes we need to deploy (5 in total). This is a big waste of time and resources. The second way it causes not only contention but outright failure is that each of these builds are operating in the same directory, and while most aspects of the build are in fact up-to-date and therefore not modified in any way, there are exceptions to this rule. The result is that build artifacts, e.g. jars are getting deleted and rebuilt from underneath competing Gradle processes, and all manner of chaos ensues, such as NoClassDefFound errors and much more. This change (reverting 'build' back to a normal, non-phony target) avoids these problems entirely. When running `make deploy`, we run the 'build' target once as a function of the 'deploy' target depending on it. At this point, the 'build' directory exists, and all subsequent node deployment targets, e.g. 'alice', 'bob', etc do not re-run the build target because it is up-to-date. For workflows where the user definitely wants to rebuild prior to redeploying a given node, they can either run `make clean-build`, or drop down to issuing Gradle build commands directly, e.g. `./gradlew :desktop:build` followed by `make desktop`.
2019-12-02 19:53:49 +01:00
# user, you'll need to manually run each of the targets listed below
# commands manually in a separate terminal or as background jobs.
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
deploy: setup
Refine deploy target for better use of `screen` Problem: Prior to this change, it was necessary to first create and attach to a screen session and then to run `make deploy` within it. This meant extra steps for the user and was generally error-prone. Solution: Usage of screen has been refined such that a screen session named 'localnet' is created on the users behalf without any need to attach to it. Individual node deployment targets such as `make bitcoind`, `make alice`, et al. are issued to new windows within the localnet screen session, and the user is free to attach or not whenever they choose. The result is that a new user can clone the repository and type nothing more than `make deploy` to get up and running with their localnet. This also reverts the changes in commit 97dd342e5 ("Make build target phony") for the following reasons: - As mentioned in that commit message, Gradle was not deleting the its 'build' directory when running `gradle clean`, meaning that the 'build' target was always up-to-date, even after running `make clean`. This made it impossible to get a correct rebuild workflow. On analysis, howewer, this situation was because of a badly behaving Kotlin plugin not cleaning up after itself, leaving a subdirectory at build/kotlin and preventing the build directory itself from being deleted altogether. To address this, the `make clean` target has been updated to `rm -rf build` instead of calling `build gradle`. While it's a workaround until we back out the Kotlin changes that caused this, it does have the added benefit of being faster than invoking `gradle clean`. - By making the 'build' target PHONY, this meant that `./gradlew build` was getting invoked every time a dependent target was called. For example, `make alice` depends on the 'setup' target, which in turn depends on the 'build' target. When calling such targets in isolation, this arrangement works out fine, because the phony 'build' target always runs, invoking `./gradle build`, and the Gradle build completes quickly assuming everything is up-to-date. The problem arises when calling a number of these targets in rapid succession, as we do when calling `make deploy` and running each individual node target in its own screen window. This causes contention in two ways. The first is that these multiple, simultaneous Gradle processes compete for access to an available Gradle daemon, and because each process needs its own, it ends up that as many Gradle daemons get created as Bisq nodes we need to deploy (5 in total). This is a big waste of time and resources. The second way it causes not only contention but outright failure is that each of these builds are operating in the same directory, and while most aspects of the build are in fact up-to-date and therefore not modified in any way, there are exceptions to this rule. The result is that build artifacts, e.g. jars are getting deleted and rebuilt from underneath competing Gradle processes, and all manner of chaos ensues, such as NoClassDefFound errors and much more. This change (reverting 'build' back to a normal, non-phony target) avoids these problems entirely. When running `make deploy`, we run the 'build' target once as a function of the 'deploy' target depending on it. At this point, the 'build' directory exists, and all subsequent node deployment targets, e.g. 'alice', 'bob', etc do not re-run the build target because it is up-to-date. For workflows where the user definitely wants to rebuild prior to redeploying a given node, they can either run `make clean-build`, or drop down to issuing Gradle build commands directly, e.g. `./gradlew :desktop:build` followed by `make desktop`.
2019-12-02 19:53:49 +01:00
# create a new screen session named 'localnet'
screen -dmS localnet
# deploy each node in its own named screen window
Avoid bash-specific syntax in makefile This fixes the problem described at [1] by replacing bash-specific array syntax with a simpler sh-friendly for loop. [1]: https://github.com/bisq-network/bisq/pull/3718#pullrequestreview-325769916
2019-12-03 11:32:38 +01:00
for target in \
bitcoind \
seednode \
seednode2 \
alice \
bob \
mediator; do \
screen -S localnet -X screen -t $$target; \
screen -S localnet -p $$target -X stuff "make $$target\n"; \
Refine deploy target for better use of `screen` Problem: Prior to this change, it was necessary to first create and attach to a screen session and then to run `make deploy` within it. This meant extra steps for the user and was generally error-prone. Solution: Usage of screen has been refined such that a screen session named 'localnet' is created on the users behalf without any need to attach to it. Individual node deployment targets such as `make bitcoind`, `make alice`, et al. are issued to new windows within the localnet screen session, and the user is free to attach or not whenever they choose. The result is that a new user can clone the repository and type nothing more than `make deploy` to get up and running with their localnet. This also reverts the changes in commit 97dd342e5 ("Make build target phony") for the following reasons: - As mentioned in that commit message, Gradle was not deleting the its 'build' directory when running `gradle clean`, meaning that the 'build' target was always up-to-date, even after running `make clean`. This made it impossible to get a correct rebuild workflow. On analysis, howewer, this situation was because of a badly behaving Kotlin plugin not cleaning up after itself, leaving a subdirectory at build/kotlin and preventing the build directory itself from being deleted altogether. To address this, the `make clean` target has been updated to `rm -rf build` instead of calling `build gradle`. While it's a workaround until we back out the Kotlin changes that caused this, it does have the added benefit of being faster than invoking `gradle clean`. - By making the 'build' target PHONY, this meant that `./gradlew build` was getting invoked every time a dependent target was called. For example, `make alice` depends on the 'setup' target, which in turn depends on the 'build' target. When calling such targets in isolation, this arrangement works out fine, because the phony 'build' target always runs, invoking `./gradle build`, and the Gradle build completes quickly assuming everything is up-to-date. The problem arises when calling a number of these targets in rapid succession, as we do when calling `make deploy` and running each individual node target in its own screen window. This causes contention in two ways. The first is that these multiple, simultaneous Gradle processes compete for access to an available Gradle daemon, and because each process needs its own, it ends up that as many Gradle daemons get created as Bisq nodes we need to deploy (5 in total). This is a big waste of time and resources. The second way it causes not only contention but outright failure is that each of these builds are operating in the same directory, and while most aspects of the build are in fact up-to-date and therefore not modified in any way, there are exceptions to this rule. The result is that build artifacts, e.g. jars are getting deleted and rebuilt from underneath competing Gradle processes, and all manner of chaos ensues, such as NoClassDefFound errors and much more. This change (reverting 'build' back to a normal, non-phony target) avoids these problems entirely. When running `make deploy`, we run the 'build' target once as a function of the 'deploy' target depending on it. At this point, the 'build' directory exists, and all subsequent node deployment targets, e.g. 'alice', 'bob', etc do not re-run the build target because it is up-to-date. For workflows where the user definitely wants to rebuild prior to redeploying a given node, they can either run `make clean-build`, or drop down to issuing Gradle build commands directly, e.g. `./gradlew :desktop:build` followed by `make desktop`.
2019-12-02 19:53:49 +01:00
done;
# give bitcoind rpc server time to start
sleep 5
# generate a block to ensure Bisq nodes get dao-synced
make block
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
Add 'make undeploy' target to kill all running nodes Problem: previously, in order to completely shut down a running localnet, users had to attach to their 'localnet' screen and kill (^C) each process, then quit and kill the entire screen session. Solution: this change introduces an 'undeploy' target that automates sending the ^C to each screen window followed by sending screen's 'kill' command to any remaining windows, thus killing the entire 'localnet' screen session. The result is that users may now run the following two commands in succession any number of times to bring their localnet up and down (to 'deploy' and 'undeploy' their localnet). # bring up localnet $ make deploy # use localnet to test, develop, etc... # bring down localnet $ make undeploy
2019-12-03 11:56:04 +01:00
# Undeploy a running localnet by killing all Bitcoin and Bisq
# node processes, then killing the localnet screen session altogether
undeploy:
# kill all Bitcoind and Bisq nodes running in screen windows
screen -S localnet -X at "#" stuff "^C"
# quit all screen windows which results in killing the session
screen -S localnet -X at "#" kill
Review "Use STATE_DIR := .localnet in makefile" This change follows up on commit 650c5894d, which: 1. Renamed the 'localdir' directory to '.localdir' to better follow convention with how local data directories are often managed, e.g. .git and .gradle. 2. Introduced the STATE_DIR variable to avoid duplication of the '.localdir' string throughout the Makefile, and at least in concept to allow this value to be customized via setting an environment variable. The changes in (1) are preserved, while the changes in (2) have been backed out. Rationale: - The STATE_DIR name introduces a new concept to the reader. They must reason about its meaning, and this works against the intention of the Makefile, which is to maximize understandability for the uninitiated. - The name, if we were to preserve the variable, probably should have been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually incorrect, but industry convention is to refer to such directories as "data directories", e.g. Bitcoin Core's `datadir` option, LND's `datadir` option and Bisq's `userDataDir` and `appDataDir` options. - The variable, whatever its name, introduces a layer of indirection, which while convenient to the makefile maintainer, is a barrier to comprehension for the reader / contributor. For example, if a user wished to copy and paste the recipe for a target, say 'bob' from the makefile, with the varible in place, the user would have to figure out its correct value and replace it before they could paste and use the copied command. Like in the first note above, the idea with the makefile is to maximize understanding for the uninitiated, i.e. working code as executable documentation. It is reasonable given this goal to increase the burden on a few maintainers in order to ease the potentially many contributors. Finally, this change follows up on the renaming of the 'localnet' directory to '.localnet' by reflecting this change in the name of the associated target as well. This is order to avoid dependent targets e.g. 'bitcoind', 'alice' or 'bob' constantly re-running the localnet target. In turn it also adds an 'alias' target named 'localnet' (without the leading dot) because targets with a leading dot are (I believe) treated as "implicit targets". In any case, they do not show up in a tab completion context, so introducing the normally-named alias fixes that. This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
bitcoind: .localnet
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
bitcoind \
-regtest \
-prune=0 \
-txindex=1 \
Enable 'peerbloomfilters' option on localnet bitcoind Problem: Bitcoind Core v0.90.0 changed the default value of its 'peerbloomfilters' option from 1 to 0, now disabling them by default. Bisq requires bloom filters be enabled on the Bitcoin node(s) it communicates with, so users who are running >= v0.90 would get errors when attempting to run `make bitcoind` with that target's current recipe. Solution: This change explicitly sets the 'peerbloomfilters' option to 1, ensuring it is enabled in any case. Note that this option has existed in Bitcoin Core since v0.12.0, so there is no real concern for this new option breaking users that are still on 0.18.x or even much earlier.
2019-12-02 20:18:38 +01:00
-peerbloomfilters=1 \
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
-server \
-rpcuser=bisqdao \
-rpcpassword=bsq \
Review "Use STATE_DIR := .localnet in makefile" This change follows up on commit 650c5894d, which: 1. Renamed the 'localdir' directory to '.localdir' to better follow convention with how local data directories are often managed, e.g. .git and .gradle. 2. Introduced the STATE_DIR variable to avoid duplication of the '.localdir' string throughout the Makefile, and at least in concept to allow this value to be customized via setting an environment variable. The changes in (1) are preserved, while the changes in (2) have been backed out. Rationale: - The STATE_DIR name introduces a new concept to the reader. They must reason about its meaning, and this works against the intention of the Makefile, which is to maximize understandability for the uninitiated. - The name, if we were to preserve the variable, probably should have been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually incorrect, but industry convention is to refer to such directories as "data directories", e.g. Bitcoin Core's `datadir` option, LND's `datadir` option and Bisq's `userDataDir` and `appDataDir` options. - The variable, whatever its name, introduces a layer of indirection, which while convenient to the makefile maintainer, is a barrier to comprehension for the reader / contributor. For example, if a user wished to copy and paste the recipe for a target, say 'bob' from the makefile, with the varible in place, the user would have to figure out its correct value and replace it before they could paste and use the copied command. Like in the first note above, the idea with the makefile is to maximize understanding for the uninitiated, i.e. working code as executable documentation. It is reasonable given this goal to increase the burden on a few maintainers in order to ease the potentially many contributors. Finally, this change follows up on the renaming of the 'localnet' directory to '.localnet' by reflecting this change in the name of the associated target as well. This is order to avoid dependent targets e.g. 'bitcoind', 'alice' or 'bob' constantly re-running the localnet target. In turn it also adds an 'alias' target named 'localnet' (without the leading dot) because targets with a leading dot are (I believe) treated as "implicit targets". In any case, they do not show up in a tab completion context, so introducing the normally-named alias fixes that. This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
-datadir=.localnet/bitcoind \
-blocknotify='.localnet/bitcoind/blocknotify %s'
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
Make 'build' target phony once again In commit 5fb4b21 ("Refine deploy target..."), the 'build' target was made normal, i.e. non-phony, but on further review it does in fact make sense to declare 'build' phony, such that it is run no matter the status of the root-level 'build' directory, but for different reasons. Previously, we had been considering the presence of 'build' directory as a reasonable proxy for determining whether the `./gradlew build` had been run. If the directory was present, we considered the 'build' target up-to-date. If not, then we would re-run `./gradlew build`. This is all sensible enough, except for the fact that the root-level 'build' directory has almost nothing to do with the actual output of `./gradlew build`. Gradle does output 'build' directories, but in the respective subdirectory for each module of the project. After `./gradlew build` has been run, we would see a 'desktop/build' directory, a 'seednode/build' directory and so forth. It just so happens that a root-level 'build' directory was getting created at all due to idiosyncracies of a particular Kotlin plugin. This commit updates the makefile to better respect this reality by: - preserving the 'build' target but marking it once again as PHONY - introducing new 'seednode/build' and 'desktop/build' targets that trigger './gradlew :seednode:build` and ./gradlew :desktop:build` commands respectively. - making 'build' depend on these two new targets In light of this realization of flawed thinking about the root-level build dir, this change also restores `make clean` to calling `./gradlew clean` instead of `rm -rf build`.
2019-12-02 21:25:59 +01:00
seednode: seednode/build
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
./bisq-seednode \
--baseCurrencyNetwork=BTC_REGTEST \
--useLocalhostForP2P=true \
--useDevPrivilegeKeys=true \
--fullDaoNode=true \
--rpcUser=bisqdao \
--rpcPassword=bsq \
--rpcBlockNotificationPort=5120 \
--nodePort=2002 \
Review "Use STATE_DIR := .localnet in makefile" This change follows up on commit 650c5894d, which: 1. Renamed the 'localdir' directory to '.localdir' to better follow convention with how local data directories are often managed, e.g. .git and .gradle. 2. Introduced the STATE_DIR variable to avoid duplication of the '.localdir' string throughout the Makefile, and at least in concept to allow this value to be customized via setting an environment variable. The changes in (1) are preserved, while the changes in (2) have been backed out. Rationale: - The STATE_DIR name introduces a new concept to the reader. They must reason about its meaning, and this works against the intention of the Makefile, which is to maximize understandability for the uninitiated. - The name, if we were to preserve the variable, probably should have been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually incorrect, but industry convention is to refer to such directories as "data directories", e.g. Bitcoin Core's `datadir` option, LND's `datadir` option and Bisq's `userDataDir` and `appDataDir` options. - The variable, whatever its name, introduces a layer of indirection, which while convenient to the makefile maintainer, is a barrier to comprehension for the reader / contributor. For example, if a user wished to copy and paste the recipe for a target, say 'bob' from the makefile, with the varible in place, the user would have to figure out its correct value and replace it before they could paste and use the copied command. Like in the first note above, the idea with the makefile is to maximize understanding for the uninitiated, i.e. working code as executable documentation. It is reasonable given this goal to increase the burden on a few maintainers in order to ease the potentially many contributors. Finally, this change follows up on the renaming of the 'localnet' directory to '.localnet' by reflecting this change in the name of the associated target as well. This is order to avoid dependent targets e.g. 'bitcoind', 'alice' or 'bob' constantly re-running the localnet target. In turn it also adds an 'alias' target named 'localnet' (without the leading dot) because targets with a leading dot are (I believe) treated as "implicit targets". In any case, they do not show up in a tab completion context, so introducing the normally-named alias fixes that. This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
--userDataDir=.localnet \
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
--appName=seednode
Make 'build' target phony once again In commit 5fb4b21 ("Refine deploy target..."), the 'build' target was made normal, i.e. non-phony, but on further review it does in fact make sense to declare 'build' phony, such that it is run no matter the status of the root-level 'build' directory, but for different reasons. Previously, we had been considering the presence of 'build' directory as a reasonable proxy for determining whether the `./gradlew build` had been run. If the directory was present, we considered the 'build' target up-to-date. If not, then we would re-run `./gradlew build`. This is all sensible enough, except for the fact that the root-level 'build' directory has almost nothing to do with the actual output of `./gradlew build`. Gradle does output 'build' directories, but in the respective subdirectory for each module of the project. After `./gradlew build` has been run, we would see a 'desktop/build' directory, a 'seednode/build' directory and so forth. It just so happens that a root-level 'build' directory was getting created at all due to idiosyncracies of a particular Kotlin plugin. This commit updates the makefile to better respect this reality by: - preserving the 'build' target but marking it once again as PHONY - introducing new 'seednode/build' and 'desktop/build' targets that trigger './gradlew :seednode:build` and ./gradlew :desktop:build` commands respectively. - making 'build' depend on these two new targets In light of this realization of flawed thinking about the root-level build dir, this change also restores `make clean` to calling `./gradlew clean` instead of `rm -rf build`.
2019-12-02 21:25:59 +01:00
seednode2: seednode/build
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
./bisq-seednode \
--baseCurrencyNetwork=BTC_REGTEST \
--useLocalhostForP2P=true \
--useDevPrivilegeKeys=true \
--fullDaoNode=true \
--rpcUser=bisqdao \
--rpcPassword=bsq \
--rpcBlockNotificationPort=5121 \
--nodePort=3002 \
Review "Use STATE_DIR := .localnet in makefile" This change follows up on commit 650c5894d, which: 1. Renamed the 'localdir' directory to '.localdir' to better follow convention with how local data directories are often managed, e.g. .git and .gradle. 2. Introduced the STATE_DIR variable to avoid duplication of the '.localdir' string throughout the Makefile, and at least in concept to allow this value to be customized via setting an environment variable. The changes in (1) are preserved, while the changes in (2) have been backed out. Rationale: - The STATE_DIR name introduces a new concept to the reader. They must reason about its meaning, and this works against the intention of the Makefile, which is to maximize understandability for the uninitiated. - The name, if we were to preserve the variable, probably should have been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually incorrect, but industry convention is to refer to such directories as "data directories", e.g. Bitcoin Core's `datadir` option, LND's `datadir` option and Bisq's `userDataDir` and `appDataDir` options. - The variable, whatever its name, introduces a layer of indirection, which while convenient to the makefile maintainer, is a barrier to comprehension for the reader / contributor. For example, if a user wished to copy and paste the recipe for a target, say 'bob' from the makefile, with the varible in place, the user would have to figure out its correct value and replace it before they could paste and use the copied command. Like in the first note above, the idea with the makefile is to maximize understanding for the uninitiated, i.e. working code as executable documentation. It is reasonable given this goal to increase the burden on a few maintainers in order to ease the potentially many contributors. Finally, this change follows up on the renaming of the 'localnet' directory to '.localnet' by reflecting this change in the name of the associated target as well. This is order to avoid dependent targets e.g. 'bitcoind', 'alice' or 'bob' constantly re-running the localnet target. In turn it also adds an 'alias' target named 'localnet' (without the leading dot) because targets with a leading dot are (I believe) treated as "implicit targets". In any case, they do not show up in a tab completion context, so introducing the normally-named alias fixes that. This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
--userDataDir=.localnet \
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
--appName=seednode2
Make 'build' target phony once again In commit 5fb4b21 ("Refine deploy target..."), the 'build' target was made normal, i.e. non-phony, but on further review it does in fact make sense to declare 'build' phony, such that it is run no matter the status of the root-level 'build' directory, but for different reasons. Previously, we had been considering the presence of 'build' directory as a reasonable proxy for determining whether the `./gradlew build` had been run. If the directory was present, we considered the 'build' target up-to-date. If not, then we would re-run `./gradlew build`. This is all sensible enough, except for the fact that the root-level 'build' directory has almost nothing to do with the actual output of `./gradlew build`. Gradle does output 'build' directories, but in the respective subdirectory for each module of the project. After `./gradlew build` has been run, we would see a 'desktop/build' directory, a 'seednode/build' directory and so forth. It just so happens that a root-level 'build' directory was getting created at all due to idiosyncracies of a particular Kotlin plugin. This commit updates the makefile to better respect this reality by: - preserving the 'build' target but marking it once again as PHONY - introducing new 'seednode/build' and 'desktop/build' targets that trigger './gradlew :seednode:build` and ./gradlew :desktop:build` commands respectively. - making 'build' depend on these two new targets In light of this realization of flawed thinking about the root-level build dir, this change also restores `make clean` to calling `./gradlew clean` instead of `rm -rf build`.
2019-12-02 21:25:59 +01:00
mediator: desktop/build
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
./bisq-desktop \
--baseCurrencyNetwork=BTC_REGTEST \
--useLocalhostForP2P=true \
--useDevPrivilegeKeys=true \
--nodePort=4444 \
Review "Use STATE_DIR := .localnet in makefile" This change follows up on commit 650c5894d, which: 1. Renamed the 'localdir' directory to '.localdir' to better follow convention with how local data directories are often managed, e.g. .git and .gradle. 2. Introduced the STATE_DIR variable to avoid duplication of the '.localdir' string throughout the Makefile, and at least in concept to allow this value to be customized via setting an environment variable. The changes in (1) are preserved, while the changes in (2) have been backed out. Rationale: - The STATE_DIR name introduces a new concept to the reader. They must reason about its meaning, and this works against the intention of the Makefile, which is to maximize understandability for the uninitiated. - The name, if we were to preserve the variable, probably should have been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually incorrect, but industry convention is to refer to such directories as "data directories", e.g. Bitcoin Core's `datadir` option, LND's `datadir` option and Bisq's `userDataDir` and `appDataDir` options. - The variable, whatever its name, introduces a layer of indirection, which while convenient to the makefile maintainer, is a barrier to comprehension for the reader / contributor. For example, if a user wished to copy and paste the recipe for a target, say 'bob' from the makefile, with the varible in place, the user would have to figure out its correct value and replace it before they could paste and use the copied command. Like in the first note above, the idea with the makefile is to maximize understanding for the uninitiated, i.e. working code as executable documentation. It is reasonable given this goal to increase the burden on a few maintainers in order to ease the potentially many contributors. Finally, this change follows up on the renaming of the 'localnet' directory to '.localnet' by reflecting this change in the name of the associated target as well. This is order to avoid dependent targets e.g. 'bitcoind', 'alice' or 'bob' constantly re-running the localnet target. In turn it also adds an 'alias' target named 'localnet' (without the leading dot) because targets with a leading dot are (I believe) treated as "implicit targets". In any case, they do not show up in a tab completion context, so introducing the normally-named alias fixes that. This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
--appDataDir=.localnet/mediator \
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
--appName=Mediator
alice: setup
./bisq-desktop \
--baseCurrencyNetwork=BTC_REGTEST \
--useLocalhostForP2P=true \
--useDevPrivilegeKeys=true \
--nodePort=5555 \
--fullDaoNode=true \
--rpcUser=bisqdao \
--rpcPassword=bsq \
--rpcBlockNotificationPort=5122 \
--genesisBlockHeight=111 \
--genesisTxId=30af0050040befd8af25068cc697e418e09c2d8ebd8d411d2240591b9ec203cf \
Review "Use STATE_DIR := .localnet in makefile" This change follows up on commit 650c5894d, which: 1. Renamed the 'localdir' directory to '.localdir' to better follow convention with how local data directories are often managed, e.g. .git and .gradle. 2. Introduced the STATE_DIR variable to avoid duplication of the '.localdir' string throughout the Makefile, and at least in concept to allow this value to be customized via setting an environment variable. The changes in (1) are preserved, while the changes in (2) have been backed out. Rationale: - The STATE_DIR name introduces a new concept to the reader. They must reason about its meaning, and this works against the intention of the Makefile, which is to maximize understandability for the uninitiated. - The name, if we were to preserve the variable, probably should have been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually incorrect, but industry convention is to refer to such directories as "data directories", e.g. Bitcoin Core's `datadir` option, LND's `datadir` option and Bisq's `userDataDir` and `appDataDir` options. - The variable, whatever its name, introduces a layer of indirection, which while convenient to the makefile maintainer, is a barrier to comprehension for the reader / contributor. For example, if a user wished to copy and paste the recipe for a target, say 'bob' from the makefile, with the varible in place, the user would have to figure out its correct value and replace it before they could paste and use the copied command. Like in the first note above, the idea with the makefile is to maximize understanding for the uninitiated, i.e. working code as executable documentation. It is reasonable given this goal to increase the burden on a few maintainers in order to ease the potentially many contributors. Finally, this change follows up on the renaming of the 'localnet' directory to '.localnet' by reflecting this change in the name of the associated target as well. This is order to avoid dependent targets e.g. 'bitcoind', 'alice' or 'bob' constantly re-running the localnet target. In turn it also adds an 'alias' target named 'localnet' (without the leading dot) because targets with a leading dot are (I believe) treated as "implicit targets". In any case, they do not show up in a tab completion context, so introducing the normally-named alias fixes that. This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
--appDataDir=.localnet/alice \
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
--appName=Alice
bob: setup
./bisq-desktop \
--baseCurrencyNetwork=BTC_REGTEST \
--useLocalhostForP2P=true \
--useDevPrivilegeKeys=true \
--nodePort=6666 \
Review "Use STATE_DIR := .localnet in makefile" This change follows up on commit 650c5894d, which: 1. Renamed the 'localdir' directory to '.localdir' to better follow convention with how local data directories are often managed, e.g. .git and .gradle. 2. Introduced the STATE_DIR variable to avoid duplication of the '.localdir' string throughout the Makefile, and at least in concept to allow this value to be customized via setting an environment variable. The changes in (1) are preserved, while the changes in (2) have been backed out. Rationale: - The STATE_DIR name introduces a new concept to the reader. They must reason about its meaning, and this works against the intention of the Makefile, which is to maximize understandability for the uninitiated. - The name, if we were to preserve the variable, probably should have been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually incorrect, but industry convention is to refer to such directories as "data directories", e.g. Bitcoin Core's `datadir` option, LND's `datadir` option and Bisq's `userDataDir` and `appDataDir` options. - The variable, whatever its name, introduces a layer of indirection, which while convenient to the makefile maintainer, is a barrier to comprehension for the reader / contributor. For example, if a user wished to copy and paste the recipe for a target, say 'bob' from the makefile, with the varible in place, the user would have to figure out its correct value and replace it before they could paste and use the copied command. Like in the first note above, the idea with the makefile is to maximize understanding for the uninitiated, i.e. working code as executable documentation. It is reasonable given this goal to increase the burden on a few maintainers in order to ease the potentially many contributors. Finally, this change follows up on the renaming of the 'localnet' directory to '.localnet' by reflecting this change in the name of the associated target as well. This is order to avoid dependent targets e.g. 'bitcoind', 'alice' or 'bob' constantly re-running the localnet target. In turn it also adds an 'alias' target named 'localnet' (without the leading dot) because targets with a leading dot are (I believe) treated as "implicit targets". In any case, they do not show up in a tab completion context, so introducing the normally-named alias fixes that. This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
--appDataDir=.localnet/bob \
Add Makefile for automating localnet setup Problem: contributors old and new must read and follow many manual steps spread across three documents (docs/{build,dev-setup,dao-setup}.md) in order to get up and running with a local regtest Bisq network deployment suitable for isolated development and end-to-end testing. This process is not only manual, but requires considerable trial and error for most contributors, and can amount to hours of effort. Perhaps most detrimental is that this friction makes it much less likely that we get "all hands on deck" to cover test scenarios at release time. Getting up and running with what this change refers to as a "localnet" should be among the very first things a new contributor does. It should be fast and easy, maximizing the contributor's ability to get productive right away. Solution: this commit introduces a simple and well-documented makefile to the root of the source tree. It instructs the user to issue a series of simple `make` commands, at the end of which they'll have a fully functional localnet deployment. Caveats: - No support for Windows unless the user is running Git Bash, Cygwin or similar. In any case, the makefile serves as clear documentation about what a Windows user would need to do manually, i.e. without the benefit of `make` automating it all. - The aforementioned setup documents should be updated to point to this makefile instead of explaining everything in prose. The dev-setup.md and dao-setup.md documents may actually be candidates for deletion if this new approach proves successful. - These changes do not include passing the new -peerbloomfilters=1 option to bitcoin versions 0.19 and above. Those who have already upgraded should take care to add that option. Notes: - The introduction of this makefile has no impact on Bisq's use of Gradle as a build system. Everything there is as it has been. This makefile is a completely optional convenience being added into the mix. It has the added benefit of being a "friendly face" to those not familiar with the Java / JVM ecosystem. Developers from many different backgrounds are familiar with make and makefiles, and they may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
--appName=Bob
# Generate a new block on your Bitcoin regtest network. Requires that
# bitcoind is already running. See the `bitcoind` target above.
block:
bitcoin-cli \
-regtest \
-rpcuser=bisqdao \
-rpcpassword=bsq \
getnewaddress \
| xargs bitcoin-cli \
-regtest \
-rpcuser=bisqdao \
-rpcpassword=bsq \
generatetoaddress 1
Make 'build' target phony once again In commit 5fb4b21 ("Refine deploy target..."), the 'build' target was made normal, i.e. non-phony, but on further review it does in fact make sense to declare 'build' phony, such that it is run no matter the status of the root-level 'build' directory, but for different reasons. Previously, we had been considering the presence of 'build' directory as a reasonable proxy for determining whether the `./gradlew build` had been run. If the directory was present, we considered the 'build' target up-to-date. If not, then we would re-run `./gradlew build`. This is all sensible enough, except for the fact that the root-level 'build' directory has almost nothing to do with the actual output of `./gradlew build`. Gradle does output 'build' directories, but in the respective subdirectory for each module of the project. After `./gradlew build` has been run, we would see a 'desktop/build' directory, a 'seednode/build' directory and so forth. It just so happens that a root-level 'build' directory was getting created at all due to idiosyncracies of a particular Kotlin plugin. This commit updates the makefile to better respect this reality by: - preserving the 'build' target but marking it once again as PHONY - introducing new 'seednode/build' and 'desktop/build' targets that trigger './gradlew :seednode:build` and ./gradlew :desktop:build` commands respectively. - making 'build' depend on these two new targets In light of this realization of flawed thinking about the root-level build dir, this change also restores `make clean` to calling `./gradlew clean` instead of `rm -rf build`.
2019-12-02 21:25:59 +01:00
.PHONY: build seednode
Reference in New Issue Copy Permalink