Why is OpenSSL needed in the official client?

[misterbigg]

Okay - can you give me the repository URL so I can have a look at it (am hoping it is github)?

I would be interested in hearing about your experiences with this, if you would care to "blog" your progress :-)

[CIYAM]

There's a link on bitcoin.org. The source code is at http://github.com/bitcoin/bitcoin.

Sorry - but I don't know how that helps me find a Visual Studio version (it is not one of the branches AFAICT).

I do have the software on my computer but it requires MingW to build (am I missing something obvious?).

[misterbigg]

I don't think its a separate branch, I think you just need to either open the existing .vcxproj (if it exists) or make a new one and add the sources to it.

[Pieter Wuille]

Sorry - but I don't know how that helps me find a Visual Studio version (it is not one of the branches AFAICT).

Well, it was not maintained, so it was removed from the repository.

Just checked, it was removed between 0.5.0 and 0.6.0. The latest makefile.vc file is here. You can use it as a starting point, but a lot changed since it was functional.

[CIYAM]

Well, it was not maintained, so it was removed from the repository.

Just checked, it was removed between 0.5.0 and 0.6.0. The latest makefile.vc file is here. You can use it as a starting point, but a lot changed since it was functional.

Thanks Pieter - but ouch - this is/was a manually maintained makefile (maybe you guys might be interested in my system that can automatically generate make files and handle dependencies even with the free VC++ compiler).

I don't know if I am really going to have enough free time to do this as I'm flat out on my own project (just have a look at how many commits I have made in https://github.com/ciyam/ciyam to get an idea) but if I do find a day or so to do this I will.

[misterbigg]

ouch - this is/was a manually maintained makefile (maybe you guys might be interested in my system that can automatically generate make files and handle dependencies even with the free VC++ compiler).

You should give unity builds a try. "SimpleDJ" in my signature uses that style.

[CIYAM]

You should give unity builds a try. "SimpleDJ" in my signature uses that style.

I'm sure there are probably several good build systems out there - am comfortable with my own as it works perfectly for Windows and Linux - but manually putting together a large makefile is definitely a huge PITA (especially if it needs to be specifically told about headers).

[Pieter Wuille]

I'm sure there are probably several good build systems out there - am comfortable with my own as it works perfectly for Windows and Linux - but manually putting together a large makefile is definitely a huge PITA (especially if it needs to be specifically told about headers).

I fully agree, and I think the other developers do as well.

It's just that all experiments with more automated build systems failed - either they didn't work for all currently supported platforms, or weren't maintained after being written.

Again, help is welcome.

[misterbigg]

I'm sure there are probably several good build systems out there - am comfortable with my own as it works perfectly for Windows and Linux - but manually putting together a large makefile is definitely a huge PITA (especially if it needs to be specifically told about headers).

Unity build is a system for organizing source files, it is not a separate tool and doesn't affect your Makefile or project file, except to make it orders of magnitude smaller. You can read about it here:

http://buffered.io/posts/the-magic-of-unity-builds

If you have Visual Studio or Xcode you can open up my "SimpleDJ" application (in my sig) and see how this all works.

[CIYAM]

I fully agree, and I think the other developers do as well.

It's just that all experiments with more automated build systems failed - either they didn't work for all currently supported platforms, or weren't maintained after being written.

Again, help is welcome.

Okay - the system I have developed works with an XML like "makefile" that is minimal (only source files and required libraries for each dependency).

It then uses OS specific "templates" that take it's structure and turn it into an actual platform specific makefile (my system can do VC++, BCB and g++ makefiles currently).

Maintenance of the system is actually very minimal (don't think I've had to change it much in the last few years actually). Header dependencies (only for VC++ in my system as both BCB and g++ handle these automatically) are handled via a specific tool (also not that complicated).

[CIYAM]

http://buffered.io/posts/the-magic-of-unity-builds

If you have Visual Studio or Xcode you can open up my "SimpleDJ" application (in my sig) and see how this all works.

Link not working in China (perhaps blocked?) - will try and have a look at that tomorrow though.

[misterbigg]

To be more specific lets look at the official client sources. The qt/ directory contains all of the source files for the associated user interface classes:

https://github.com/bitcoin/bitcoin/tree/master/src/qt

We have

aboutdialog.cpp
aboutdialog.h
addressbookpage.cpp
...
walletmodel.h

Right now each of these is individually mentioned in the Makefile. What we could do instead is create a new "unity" .cpp / .h pair of files and manually #include these sources:

qt_ui.h

Code:

#include "aboutdialog.h"
#include "addressbookpage.h"
...
#include "walletmodel.h"

qt_ui.cpp

Code:

#include "aboutdialog.cpp"
#include "addressbookpage.cpp"
...
#include "walletmodel.cpp"

Given, it looks a little strange with .cpp files as includes, but the results are quite impressive. You can remove all of the #include lines from every associated .cpp and .h and just merge them into one non-repeated group of includes at the top of qt_ui.h and qt_ui.cpp. Preferably the bulk of includes would go into qt_ui.cpp (so they have a smaller scope).

It is instantly possible to see what the group of classes external include dependencies are (they are all in one place).

Adding, renaming, or removing individual UI component source files is done by editing the .h and .cpp, no changes to the Makefile are required. All of the individual .cpp / .h in the Makefile are replaced with the one qt_ui.h and qt_ui.cpp pair.

It is true that the granularity of compilation now becomes this larger set of classes, but the trade-off is well worth it.

[CIYAM]

The tool for VC++ that I am using just scans all the quoted #include's from the source files to work out the dependencies.

Provided you stick to a consistent coding style it solves this problem easily and without anything weird (just requires a couple of tools and the makefile template).

[keystroke]

What are the advantages of LevelDB vs BDB?

[Pieter Wuille]

What are the advantages of LevelDB vs BDB?

Faster, less prone to corruption (in our setting), better compatibility between versions. At least, hopefully.

Also see this SE question.

[misterbigg]

Why not sqlite for the wallet (and maybe the blockchain) ?

[CIYAM]

Why not sqlite for the wallet (and maybe the blockchain) ?

Although not familiar with LevelDB I can say I was quite impressed with SQLite (used to use it for my own project although unfortunately it's not designed for concurrency due to its rather global locking approach).

[misterbigg]

I was quite impressed with SQLite (used to use it for my own project although unfortunately it's not designed for concurrency due to its rather global locking approach).

SQLite works great with multithreaded apps you just need to set the appropriate locking model option. If you mean concurrency in the sense of different processes accessing the same database then yeah I agree (but that's not SQLite's target audience).

[CIYAM]

SQLite works great with multithreaded apps you just need to set the appropriate locking model option. If you mean concurrency in the sense of different processes accessing the same database then yeah I agree (but that's not SQLite's target audience).

Interesting - my problem was actually with multi-threading not different processes - will have to look into that again if they have improved the locking (I last looked at that a few years back).

[Pieter Wuille]

Why not sqlite for the wallet (and maybe the blockchain) ?

In my opinion, even sqlite is overkill for the wallet. It's yet another dependency (something you don't like, right?), and all we need is a simple key-value store that is read at startup and loaded into memory. Probably we'll move to a very simple custom append-only format with checksums.

For the blockchain: performance. LevelDB is exactly what we need: not more than a key-value store with atomic writes, with very good performance and consistency.