Topic: Proposal: make it so anybody could easily compile the client (Read 2561 times)

It is more difficult to compile anything on windows by default.
If you want to EASILY compile things, move to an Open Source UNIX-like system (such as Linux), which is designed for ease of compilation by default.

However, having a proper ./configure script on UNIX/Linux wouldn't hurt. For now it is not possible to do the following on the Bitcoin client sources:


Which is a little annoying. Other then that, compilation on UNIX is not problematic.

I finally got it to work, my issue was that I had two different versions of openssl, one with includes at /usr/local/include/openssl and the other with /usr/include/openssl, and they were managing to include one another's include files due to the way the include search path apparently works.  Would yield screenfuls of compile errors all related to ECDSA.  So removing one of them solved the problem.

SO yeah, that's not the fault of the Bitcoin project.  But having a list of the dependencies and the typical instructions to install them (either HTTP URL, git clone path, apt-get package name, etc.) in the README wouldn't hurt.

makefile.unix?  What OS are you compiling on?

You can submit a pull request to the core project on github, I believe.

I too am frustrated by difficulty getting this to compile (on Linux).

I too want to contribute a little here and there.  Even if the README was a bit of a HOWTO that said go get this, go get that, I'd do it.

I am hoping that someone will be able to walk me through getting past whatever is throwing me for a loop.  It looks related to OpenSSL.

http://pastebin.com/wYDFLzds

+1 to Alex Zee point.


I never fiddled with the sources myself, because my time is too precious to waste trying to compile stuff.

Well, I finally managed to create a stand-alone 1-click Windows build.

You can download it here (25 Mb):

http://qbizy.com/bitcoin-one-click-win-build-0.4.0rc2.7z

It's based on the latest official version (0.4.0 RC 2).

You will need Visual Studio 2005 to build it (if you'll manage to compile it in later versions - please post here).

--

The source code is not modified in any way, except one line in the "util.h" - I've added "typedef int pid_t;" because it didn't recognize this type.

The code that uses it should probably be #ifdef'ed with "__WXMSW__". Developers, please fix it!

Another thing - the "bitcoin.ico" converted to uncompressed format so VS's resource compiler would understand it.

Also, developers, please put the updated icon into the main distribution:

http://qbizy.com/bitcoin-vs2005-compatible-ico.zip

--

No UPNP yet. Is it important? No daemon too. Latest OpenSSL 1.0.0e is used instead of 1.0.0d.

EXE file size is 6 instead of 11 Mb.

Still tries to load "WMIApSrv" driver, same as the official client. Need to find how to turn this off...

To save space only the essential dependencies were included. For example, no debug libraries. All the added Windows stuff is in the single "windows" folder.

Comments and ideas appreciated.

This is what my pushpool/bitcoin installer does. I can set up a new (Linux) pool server in minutes without having any of the dependencies on the machine.  No, I won't share it, it's a mess and is quite brittle

License questions aside, it can be difficult to include all the required dependencies for a project, particularly anything built in C++ on Windows.  Windows/MSVC runtime has a *&(@$ load of library dependencies it doesn't advertise that can bite you hard when deploying an application.  The redistributables do a good job of addressing 99.8% of the problems so usually just distributing the msvc redistributables will do the job, but then there are the edge cases...

Qt's full build is over 30 GB.  The core libraries (release) are only a couple hundred kb, but debug ones are about 10gb total.  Any developer will need the debug ones if they want to do their own compiling without worrying about dependencies.  I know of no place currently that will host binary lib drops that big, so cuts/choices would have to be made - a Qt GUI project could include only the QtGui.dll and QtGuid.dll files, which amounts to about 10 MB. But you wouldn't be able to link/include functionality from any other Qt libraries.

The situation is much simpler with the .NET Framework on Windows. It includes everything, and because you can run the framework installer as part of a setup package, you don't even need to include the framework, just include the redistributable installer.  And because with .NET, a dependency list is as simple as a list of DLL's you drop in your exe dir, including non-Framework libraries is trivial.

Remember, all this is licensing aside.  Redistribution is a hot topic in software licensing and you can get burned pretty badly by it if you're not careful.

I am glad to see a person who thinks like me.

+1 AlexZ!

Ok, what I will do is create a separate package with a single addition - a "windows" folder where I will put everything required to build it on Windows.


That's kinda vague

When do you guys plan to make the official 0.5 branch?

Is it possible to make a bat that uses wget to download all sources?

This is not possible license-wise. You can externally release a tarball with all source code and dependencies, if you make it clear that it includes project+dependencies.

However, including the source and headers of entire frameworks such as boost and Qt into the git branch would be extremely unwise and also wasteful of space. LGPL and GPL allow linking against, but not copying the files into your project, except by making the entire project (L)GPL.

If you don't believe that, name one project that does this...

It's in the process of being merged.

You raise valid points.

But if we want to attract more developers to Bitcoin, and not only "core full-time" developers, but people who will do minor optimizations and bug-fixes in their little spare time, we need to have a one-click setup. It's crucial.

Yes, a developer might use some other libraries, but they can be of different versions. And most importantly - our hypothetical developer probably wouldn't care if they will be duplicated in Bitcoin distribution.

He installed the Bitcoin client, he noticed a bug or had an idea for a "20-minute work" feature. All that he needs is to go to the "source", click on solution, make some tweaks in code, fix a bug, whatever, and compile himself a new binary.

If he is required to spend 40 minutes on top of those 20 minutes just to make it compile, he might just give up.

So, Ok, if there are nobody else to do a full Windows build, I will do it.

But now I am confused, which version to work with. Is your bitcoin-qt going to be the new official master branch as is? Or will there be some kind of merging process?

No I don't. I don't even have Visual Studio and rarely use Windows. And when I do I use the Qt SDK with Qt Creator, for which I also published the four simple steps for building in the README file...

Because on non-windows platforms it is not normal to bundle all the libraries a project makes use of. They are installed as separate packages.

Even on Windows, many people already use the libraries such as boost and openssl so have them installed in their own locations.

Releasing a tangle of source files that include copied boost, upnp, openssl headers and source files would certainly be useful for some people, but could also create more problems than it's worth.

Yes, maybe you should do that. That's a much better attitude

You realize those libraries might be published under different licenses, some of which would prevent him from redistributing them? I dont know if its the case here, but you usually cant just go and put "everything thats needed" in a tarball for your convenience.

BTW, I just compiled bitcoin-qt. Copy pasted 3 commands (yes, I use linux) and its working and looking great. Thank you John Smith.

Let's make it practical.

If you don't have time to create VS projects - let me do it.

Developers. Do just this step one: include all the source into the main branch. QT includes, what have you. All. No downloads required.

I will do the projects.

Because you already have all the libraries installed! You already have it set up!

Why don't you just publish the whole project, not just a part that requires lots of dependencies?

If you dare me, hell, sure, I can do it. I would be glad to help all the future possible developers who might want to get involved.

It just would be much easier for you, since you already have it on your machine.

Besides, the "full" distribution should be supported by those, who work on it "full time".

It would be cumbersome for me to follow your release schedule and update a stand-alone "full" package for others.

Then why not do it and contribute the result, to save "all those many other people" the work.

Oh wait, this is just about you.

It's funny how such a simple thing as bundling all the libraries, since you already have them, and creating projects for them becomes an "unreasonably high requirement".

Of course, it's better to not include them for no reason whatsoever and then force everyone who will try to help you develop the project to spend time jumping from site to site, searching for the exact versions, downloading and placing into proper folders and doing the whole setup again.

"Come on in, developers, help me develop it! But you need to dance for an hour and upload the video of your dance on YouTube, before I let you work on my project!"

That's a cool attitude. It goes great with "hey, I am not being paid, so I am free to do a crappy job".

Developers are few and people who will be using their project are many. That's enough reason to try and make it as easy for them as possible, to save their time and not yours.

But whatever.