CMake cleanup & MinGW support

[crypto-ape]

Hey Monkeys!

I have cleaned up the CMake scripts for the main project also, and made some improvements:

• removed unused and irrelevant code
  • old and not supported Boost library handling routines, TCL and BDB references
• MinGW support ( supports building Windows binaries on Linux )
• enforcing more strict compiler warnings and errors

Python helpers:

• rewritten cat-parts and embed_genesis helpers into Python
  • simplifies cross build
  • can be manually turned off with GENERATING_HELPERS CMake parameter
• if Python is not found, the build continues in the usual way
• works on Windows / Linux / Mac

I have also enabled code fortification mechanisms

• FORTIFY_SOURCE, safe-stack, stack-protector, ...

Related: bitshares/bitshares-fc#121

Ape out!

[pmconrad]

What I really dislike about this PR is the huge load of new CMake modules. Is that really necessary?

I'm all for simplifying the build process, but adding 3kLoC only for replacing cat-parts and embed_genesis with python equivalents is not really it.

[crypto-ape]

Well, I kind of agree with you. I was not sure about adding those files, neither.

In the meantime, I have come to an idea that would support older CMake 3 versions, and would not require so many supporting files.

This PR was not just about replacing cat-parts, and embed_genesis, but also about cleaning up the unneeded and confusing parts of CMake scripts.

[abitmore]

Being able to "fallback" to old C++ cat-parts means we have to keep both the C++ code and the new python script in the code base? What will we gain by doing so?

[crypto-ape]

Being able to "fallback" to old C++ cat-parts means we have to keep both the C++ code and the new python script in the code base? What will we gain by doing so?

Yes, you are right. Both versions would have to be present.

Mostly, lowering requirements for the most common use case, making the build easier for the curious user.

The technical trad-off is of course the need to keep the both versions in sync.

On the other hand, it seems to me that this would be of no serious concern, because the functionality of embed_genesis and cat-parts is stable and would not require much modifications in the future.

[crypto-ape]

Hey Monkeys, It's me again.

I was working the fix for the fc subroject, and now it is finally working.

Here is what is updated since the initial commit.

• Updated FindPython and FindBoost, both are more future-proof
  • rewritten FindPython to be a lightweight wrapper for FindPythonInterp, if FindPython is not available ( CMake < 3.12 )
• FindBoost
  • uses config from fc subproject
    • the configuration is in one place
  • the fc does some FindBoost magic
• parallel (multiprocessed) embed_genesis Python script - speed improvement while processing large genesis files

This project requires updated version of fc to compile (namely the BoostConfig.cmake file)

[abitmore]

Travis complained:

CMake Error at CMakeLists.txt:116 (add_subdirectory):
  add_subdirectory given source "libraries/fc/CMakeModules/Legacy" which is
  not an existing directory.
CMake Error at CMakeLists.txt:147 (FIND_PACKAGE):
  Could not find a package configuration file provided by "Boost" with any of
  the following names:
    BoostConfig.cmake
    boost-config.cmake
  Add the installation prefix of "Boost" to CMAKE_PREFIX_PATH or set
  "Boost_DIR" to a directory containing one of the above files.  If "Boost"
  provides a separate development package or SDK, be sure it has been
  installed.

Need to merge bitshares/bitshares-fc#121 first, then bump FC?

[pmconrad]

See comment above:

This project requires updated version of fc to compile (namely the BoostConfig.cmake file)

[pmconrad]

bitshares/bitshares-fc#121 has been merged, please rebase and bump fc.

[crypto-ape]

I have failed to compile the most up-to-date, develop with fc:master, branch, because of issues unrelated to this PR.

There is some other refactoring in the fc submodule which probably causes this failure.

Excerpt from compilation log:

libraries/protocol/include/graphene/protocol/object_id.hpp:171:17: error: ‘true_type’ in namespace ‘fc’ does not name a type
     typedef fc::true_type  is_defined;
                 ^~~~~~~~~
/libraries/protocol/include/graphene/protocol/object_id.hpp:172:17: error: ‘false_type’ in namespace ‘fc’ does not name a type
     typedef fc::false_type is_enum;

After fixing this, another issues with uint128 arose.

It seems to me, that the develop branch in its current form is not usable with the fc:master branch, and consequently neither is this PR branch.

[pmconrad]

Right, sorry. fc/master requires changes from #1789 . There are still some issues in there wrt windows + mac builds, that's why it hasn't been merged into develop yet.

[pmconrad]

@crypto-ape please rebase on latest develop. #1789 has been merged in so there shouldn't be conflicts anymore.

[crypto-ape]

@pmconrad Working on it. Will push tomorrow if nothing unexpected happens.

[oxarbitrage]

@crypto-ape any chance to get this done today ? we will want to include this in the current release that we are closing today. I can try to fix conflicts but will be better if you can take it.

Thank you very much and let us know.

[crypto-ape]

@oxarbitrage I have pushed the changes, hopefully it will build.
Later, for sure I will have to commit a fix for Windows & MinGW.

Otherwise,
Linux, and Windows with MSVC should work well.

[crypto-ape]

@oxarbitrage, @pmconrad It is done, hopefully it is enough for now.

[abitmore]

It's likely that we'll process this PR after merged #1992 which bumps FC, so the FC bump in this PR will be unneeded.

[pmconrad]

Merged #1992, please rebase on latest develop (again, sorry) and get rid of the fc bump.
Will test develop build with gitian.

[crypto-ape]

@pmconrad please review, updated according to your suggestions.

I have tested, seems to work on all platforms, except for the problem with cli_wallet where the wallet.cpp fails for MinGW.

[pmconrad]

Thanks!