Page MenuHomePhabricator

Added a script to generate chainparams intermediate files

Authored by jasonbcox on Jul 24 2019, 21:49.



First step to generating chainparams header files. Next step is to
generate the header file based on the output of running this script
once for each chain.

In the near future, this pipeline becomes possible (all TODO):

  • A bot with up-to-date nodes runs this script.
  • Chainparams header is generated.
  • Smoke tests are run on the result and landed on master automatically.

For now, this script can be used manually.

Split off from D3502. This iteration achieves a simpler design by being split
into two steps.

Progress towards T663

Test Plan
make check-devtools
ninja check-devtools

# show help message --help

# errors due to missing config/config params -c blah
vim ~/.bitcoin/bitcoin.conf # add rpcuser
vim ~/.bitcoin/bitcoin.conf # add rpcpassword

# generates mainnet output

# generates testnet output
bitcoind --testnet -a ""

Diff Detail

rABC Bitcoin ABC
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline
279 ↗(On Diff #10447)

Due to the weird way that python handles relative imports, the test needs to be run in it's own directory. Similar to how source lists are done, I would have made a list of devtools tests. But, it wasn't clear how to iterate over that list in order to cd into the directory that each test is contained in (or even if automake supports this sort of looping behavior). If there's a better way to future-proof this for multiple tests, let me know.

Fabien requested changes to this revision.Jul 26 2019, 09:27
Fabien added a subscriber: Fabien.

You can also loop over devtools using cmake by simply creating a list set(DEVTOOLS /contrib/devtools/toolA /contrib/devtools/toolB /contrib/somethingelse/toolC) then use a foreach loop to create the command.
You can use the get_filename_component function to extract the directory and the script name:
279 ↗(On Diff #10447)

Yes, there is a better way using automake automatic variables, see

In your case I think this cryptic snippet should work (untested):

@echo "Running devtool test $<"
@cd $(<D) && $<
This revision now requires changes to proceed.Jul 26 2019, 09:27
  • Fixed make check-devtools to iterate over a list of devtools tests
  • Simplified cmake check-devtools to work in a similar way as the make build, making it easier to add tests.
jasonbcox added inline comments.
279 ↗(On Diff #10447)

Thanks. Even knowing what to look for, this was not easy to Google around for.
281 ↗(On Diff #10504)

There is something integrated in autotool ot run tests. Use it.

The test plan is a mix of comments and command without distinction, which makes it impossible to follow.

deadalnix requested changes to this revision.Aug 5 2019, 07:04
deadalnix added inline comments.
12 ↗(On Diff #10504)

Is that how it's done ?

Also, clearly, this isn't a piece of the test framework anymore, so more refactoring is in order.

This revision now requires changes to proceed.Aug 5 2019, 07:04
jasonbcox added inline comments.
12 ↗(On Diff #10504)

I did it this way due to the way python handles imports. Python normally expects imported modules to reside in sub-directories. Currently, a majority of the python code lives in test/functional/*. While it would be ideal to move the shareable test framework code into the src tree, the tests would no longer be able to import it correctly. Even more ideally, all of the python tests + python devtools would move under a common directory structure. Considering the harm this would do to the backporting effort, I opted not to take this approach. The approach done here is intended to be short-term until the test framework backports are in order.

  • Added check-devtools to make/ninja check
  • Ignore linter warning about imports at top of the file
This revision is now accepted and ready to land.Sep 5 2019, 19:27