Use Peter's Alpine Linux Docker work

[bobsummerwill]

Says @karalabe,

Btw, if I try to build cpp-ethereum on 8 cores, it almost always fails with

 /cpp-ethereum/libdevcore/Common.cpp:25:36: fatal error: cpp-ethereum/BuildInfo.h: No such file or directory
compilation terminated.
libdevcore/CMakeFiles/devcore.dir/build.make:206: recipe for target 'libdevcore/CMakeFiles/devcore.dir/Common.cpp.o' failed
make[2]: *** [libdevcore/CMakeFiles/devcore.dir/Common.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....

seems the build system is racey and doesn't build some dep before wanting to use it

I've put together an Alpine cpp-ethereum images
It seems to work, but all the shared libraries that cpp-ethereum depends on is gigantic
I've managed to slim it down by only keeping the essential packages without which I get library errors
but even with this it's 1+GB
I'm a bit amazed tbh )
Here's the Dockerfile nonetheless, perhaps you guys can use it to assemble your alpine build scripts or whatnot
https://gist.github.com/karalabe/ddc3296c04adf724b0a7f9eb45e19052

[bobsummerwill]

Hey @karalabe!

Many thanks for that, Peter.

Yeah - I can completely believe the race-condition one. That probably means that we are missing a dependency edge somewhere. I will investigate.

As of the 1GB+ of external dependencies, I can absolutely believe it. Just Boost can be 500MB.

Most of the content is obviously not used in our case, but we have dependencies onto small parts of huge libraries. Boost is the worst, but others are large too.

I think it is mainly indicative of the fact that the C++ standard library (while growing) has typically been a much smaller, more conservative, set of functionality than is the case in more modern languages. So we have a lot of external dependencies.

All these white ones:

http://www.ethdocs.org/en/latest/ethereum-clients/cpp-ethereum/architecture.html

We should look what kind of consolidation is possible between this Dockerfile and

https://github.com/ethereum/cpp-ethereum/blob/develop/scripts/install_deps.sh#L175

See ethereum/webthree-umbrella#633

Looks like we've not got around to adding Alpine support there yet, where we have done so for Solidity (which is simpler, but we would have much the same form):

https://github.com/ethereum/solidity/blob/develop/scripts/install_deps.sh#L163

Hey @rainbeam!

ethereum/webthree-umbrella#495

[bobsummerwill]

Hmm ... so about buildinfo.h, that is very odd.

In the top-level CMake file, there is a call to configure_project(), which calls create_build_info():

https://github.com/ethereum/cpp-ethereum/blob/develop/cmake/EthOptions.cmake#L102

For the Makefile generating flow, that seems to end up with a Phony target in build/Makefile:

.PHONY : cpp-ethereum_BuildInfo.h

I don't see any makefile dependencies onto that target for the targets for building the other libraries, which is what I would expect to see. Not sure what semantics would normally be followed there for phony targets in a multi-core make invocation. Anybody know better than me?

@chfast @karalabe @chriseth?

I expect that we need to do something in the CMakeLists.txt files for the libraries which use those generated header files to add that dependency edge into the generated Makefiles.

I wonder whether this is something which I broke as part of the CMake cleanup, or whether we have just had this issue forever, and never noticed it because we're mainly building within mininal "fan-out"?

[chriseth]

Buildinfo.h is generated in the make step by a cmake script. I think it has been like that all the time.
Note that it has to be part of the make step because we want to detect modified source.

[bobsummerwill]

I'm just wondering whether something more than just that phony target is needed for complete correctness here, @chriseth?

None of the other targets depend on that phony target. Should they?

[chriseth]

Not sure, probably.

[chfast]

We have docker image based on Alpine. But it sometimes crashes :).