fixed contrib/gitian-descriptors for Linux 32, Linux 64, Windows 32 an OSX

[schinzelh]

• fixed contrib/gitian-descriptors for Linux 32, Linux 64, Windows 32 an OSX
• updated macdeploy/macdeployqtplus to latest bitcoin upstream
• updated release-process.md

known issues:

• setup.exe for Windows 32 is still branded as Litecoin
• test of upload of signatures to gitian.sigs pendig
• build system (makefile, darkcoin-qt.pro) is outdated and needs update to autotools/autoconf
• Windows 64 build not working due to linker issues

[darkcoinproject]

Very exciting! Thanks so much. I'm compiling all of this right now and seeing if I can make the binaries.

[schinzelh]

Compiling the intermediate inputs will take the most time - especially Qt. Complete build cycle was about ~4hrs on my AWS instance.

Good you only have to build them once initially, and then only if dependencies are updated

[DeathRay1977]

Another thing that will improve build times is splitting up main.cpp. That file is monolithic! If all classes were split up into their own individual files with one class per file and only included in sources that need that class, then build would be much more efficient. You only have to change a comment in main.cpp to trigger the rebuilding of lots of files. If you change a class in main.cpp, then everything gets rebuilt even if they do not use that class. I know this code was inherited from Bitcoin but we should maybe think about refactoring it? I am guessing Satoshi never read Myers' Effective C++ book! Also #include guards would be helpful so that the preprocessor only includes a header once during compilation. There are too many files with more than one class defined/declared in them. In the long term, it will make for some very hard to maintain code.

[schinzelh]

Yeah, i agree with @DeathRay1977 - there is a lot of refactoring potential, especially in the monolithic 6000-loc super master main.cpp - beside Myers' book Satoshi should have read "Clean Code" by Robert C. Martin :D

From looking at the bitcoin-repo the devs started refactoring the bitcoin codebase as well. They even split out a bitcoin-cli from main.cpp to separate the RPC client from the bitcoin core.

Before we can start refactoring we will need more test coverage, otherwise we are in danger to break things too easy. I will set up a SonarQube server for the coverage analysis...

@darkcoinproject Regarding the build process/system: For the short term (RC4/5) i am planning to integrate the autoconf/autotools approach which bitcoin uses since 10 months. That way we can

a) get rid of architecture specific makefile.*-files - just "./autogen.sh ; ./configure ; ./make"
b) easier optimize the include headers as there will be a config.h file generated which can be used for this purpose

Additionally i propose to merge all changes to litecoin codebase since forkpoint (Litecoin v0.8.6.2) to Darkcoin - there have been some important (security relevant) fixes to Litecoin since January.

[DeathRay1977]

Having autoconf/autotools in the future would be a giant leap forward! Awesome!! Can't wait!

[flack]

Is the naming change intentional?

[schinzelh]

Actually no, well spotted - @darkcoinproject please change the reference back to DarkCoin-Qt. Thanks!

[flack]

Well, as long as it's not merged yet, you can simply correct it in your branch, commit & push again. The PR will then automagically be updated

[schinzelh]

Thanks, worked like charm! Was not aware that pull request can be updated like that :)

[darkcoinproject]

@DeathRay1977 Splitting up main.cpp sounds like a fantastic idea. I spend way too much time waiting for things to compile that could otherwise be spent coding. If you want to do that I would fully support that. Although, you should wait a couple weeks because I'm restructuring a bunch of stuff and it will cause conflicts and a headache

[DeathRay1977]

I would love to get stuck into refactoring main.cpp as it's much needed. I will wait till after the next spork though. I have already pulled out the Darksend stuff into their own files but I won't issue a pull request and can retrofit your latest changes first. It's going to take a while to unravel the spaghetti code in main.cpp though. I would probably not want to release it in one big pull request.