Refactoring - Sever libethereum dependency for ethminer

[bobsummerwill]

From @bobsummerwill on July 22, 2016 20:53

See dependency diagram for the re-formed cpp-ethereum repository:

It looks like it might be possible to sever ethminer from any dependency on the C++ runtime with a little refactoring in ethashseal - pulling the mining-specific parts out into ethminer itself and removing the mining command-line options from eth.

That would make ethminer dependent only on ethash and ethash-cl - not on any other parts of the cpp-ethereum repo.

So @Genoil and @chfast - you guys will know a lot better than me - are there significant dangling tentacles beyond that? Other parts of ethashseal. Types and so on in ethcore and devcore, which would need orphaning out, as I have been doing for Solidity?

This would be with a view to upstreaming your changes, @Genoil, (#3124 and #3125) and then extracting ethminer into its own package.

Also CC @chriseth, @gavofyork, @smartbitcoin, @General-Beck, @wolf9466, @Equinox-, @LefterisJP, @debris, @arkpar.

And please do feel free to add anybody else with insight into the dependencies of ethminer.

Copied from original issue: ethereum/webthree-umbrella#675

[bobsummerwill]

Adding @tswindell.

[bobsummerwill]

OK, so just about everything appears to be happening inline in here:

I managed to strip that down to the following:

#include <libdevcore/CommonJS.h>
#include <libethcore/BasicAuthority.h>
#include <libethcore/Exceptions.h>
#include <libethashseal/EthashGPUMiner.h>
#include <libethashseal/EthashCPUMiner.h>

#if ETH_ETHASHCL
    #include <libethash-cl/ethash_cl_miner.h>
#endif // ETH_ETHASHCL

[bobsummerwill]

OK ... Looks like this is essentially the scope of the dependencies:

• byte and bytes definitions
• FixedHash type
• toJS() functions
• Exception classes which can likely be moved very easily
• BasicAuthority, Ethash, NoProof
• EthashCPUMiner, EthashGPUMiner
ethash_cl_miner

[nerdralph]

As mentioned in #3228, you can't build ethminer without all the dependencies of the other tools/libs. One specific example is libp2p, which requires cryptopp. ethminer doesn't require it, but cmake fails before it can generate the makefile for ethminer:

CMake Error at cmake/FindPackageHandleStandardArgs.cmake:138 (message):
  Could NOT find CryptoPP (missing: CRYPTOPP_INCLUDE_DIR CRYPTOPP_LIBRARY)
  (Required is at least version "5.6.2")
Call Stack (most recent call first):
  cmake/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE)
  cmake/FindCryptoPP.cmake:107 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  cmake/UseCryptopp.cmake:2 (find_package)
  cmake/EthDependencies.cmake:203 (eth_apply)
  libp2p/CMakeLists.txt:9 (eth_use)

[bobsummerwill]

Yeah ... I see the distinction you are making.

My preference on getting that trimmed-down Makefile generation is just to get the repository boundaries correct, rather than constraining with BUNDLEs. For ethminer, that will mean carving it out into its own repository when we have the dependencies minimized. Also, that only makes sense after upstreaming @Genoil's ethminer edits.

[nerdralph]

Having looked at both codebases, forking Genoil's code may be the easiest option.

[bobsummerwill]

Upstreaming should be equivalent, because nothing much has changed in the upstream since the fork was made.

[nhp3007]

Hi,
I'm just getting started with open-source and I'm interested in this refactoring task as I think it will help me get familiar with how the code for cpp-ethereum is organized. Is this is a good task for a someone getting started with this project?

[chfast]

We moved ethminer to separated repo https://github.com/ethereum-mining/ethminer. This one is not useful any more as it has not GPU support. The other one has OpenCL + CUDA + stratum. If you want make it better the other repo is the place to start from.

Sorry for confusion...

[nhp3007]

No problem. I will look at that repository to see if I can contribute there. I have a little experience with CUDA programming. Thanks for the update though.