This pull request aims at adding autotools for build checks, configure flags for compile time configuration and handling of #define directives inside code and things that will possibily make it better for bitcoin to be packaged inside distributions, as well ported to different architectures.

Build of this branch was tested on Debian 6 (also with WX GUI), Apple OSX 10.5 (no WX GUI) and CYGWIN win32 (no UPNP nor WX)

completed

add autotools build system

• commit ref: jaromil@500da9eb20d480c431d610472bfa3af92112aead

  this pull request follows as third attempt to previous 2:

  • #162
  • #177

  and basically consists of a rebase of this branch https://github.com/jaromil/bitcoin/commits/master eliminating all those commits and squashing them in 2 steps.

  1st commit moves files around under old build system

  2nd commit converts the build system to autotools (while we still leave the old build system in place, optional)

the bitcoind code itself was never modified: files were moved around and the header auto-config.h generated by autoconf was added to headers.h

code modules have been separated in subdirectories and compiled as static libraries, still using libtool, which is the recommended behaviour when using autotools.

interesting configure flags

• --enable-upnp=0/1 has been added and configure.ac contains templates for adding more compile time choices in future.
• --enable-gui has been added also to activate compilation of the included WX GUI. other wx related flags are provided to indicate prefix or static library build.
• --enable-debug compiles the binaries with debugging flags, giving all warnings - anyone willing to help should run it at least once :)
• --enable-profiling enables support for gprof the GNU profiler (will dump gmon.out files after run)
• --with-wxdir=PATH Use uninstalled version of wxWidgets in PATH
• --with-wx-prefix=PREFIX Prefix where wxWidgets is installed (optional)
• --with-boost and more boost build configuration

code re-organization

• commit ref: jaromil@84c3fb07b0b8199c7f85c5de280e7100bad0786f

  directory re-organization (keeps the old build system)

  there is no internal modification of any file in this commit

  files are moved into directories according to established standards in sourcecode distribution; these directories contain:

  • src - Files that are used in constructing the executable binaries
  • doc - Files in HTML and text format that document usage, quirks of the implementation, and contributor checklists.
  • locale - Files that contain human language translation of strings used in the program
  • contrib - Files contributed from distributions or other third party implementing scripts and auxiliary programs

Small aesthetical error:

checking for wxWidgets static library... no
checking if compiling with debugging symbols... no
no
configure: creating ./config.status

The name of the generated binary seems to always be bitcoind, whether or not a GUI is included. If you're going for the "one binary, with some optional features", I'd call it bitcoin instead of bitcoind.

Apart from that, it looks clean and seems to configure, compile and run fine.

hi sipa,

i've investigated the issue behind double binary build: bitcoin and bitcoind the solution to it becomes groovy, to the point that makes me wonder about changing this naming scheme.

long story short: if we keep this, then all code in src/ will be compiled twice by make, with and without #define flags that activate the gui.

CPU cycles are worth :^) and as we proceed cleaning the code for a libbitcoin, then libtool will do its job and we'll have separated directories and test units. but let's leave that to the next pull request.

the next commit implements bitcoin and bitcoind build (current behaviour) and shines up some cxxflags

Several things: 1. If you are making a pull request, you might as well just git push -f to overwrite the old commits with new ones instead of making new pull requests all the time. Github will change the pull request accordingly (unless you change the branch to match master, at which point Github closes the pull request for you). 2. You don't ship the ./configure Is that a bug or am I missing something?

hi TheBlueMatt,

On Sun, 24 Apr 2011, TheBlueMatt wrote:

1. If you are making a pull request, you might as well just git push -f to overwrite the old commits with new ones instead of making new pull requests all the time.

wow! i didn't knew that and it saves me quite some time clicking around.. thanks :D

1. You don't ship the ./configure Is that a bug or am I missing something?

the 'configure' file is automatically generated by autoconf from configure.ac which is the main sourcecode for this build system.

in order to generate it, run: 'autoreconf -i'

the configure file itself is never included in code revisioning, but only in tarball releases.

tarballs can be produced very comfortably with 'make distcheck'

jaromil, dyne.org developer, http://jaromil.dyne.org GPG: B2D9 9376 BFB2 60B7 601F 5B62 F6D3 FBD9 C2B6 8E39 Donate Bitcoins to: 1EJYtvuq39hoWcventcnnvhPXh6i5QDReM

speaking of which, i've just noticed the 'distcheck' target fails to compile.

that compilation target actually is there to facilitate tar.gz releases, but also to verify that the autotools packaging is well portable and working in all situations... so i'm having a look to fix that now in the next commits.

Pull request is now rebased to an acceptable state.

Looks great!

One final blocker: cryptopp should not be built using the libtool machinery. All that accomplishes is making it slow, and creating an annoying build process where "make -s" does not work properly.

All references to libtool should be removed, and cryptopp should be built via noinst_LIBRARIES = libcryptopp.a

I support this re-org; jgarzik, can you do the pull when you're happy?

The READMEs and build-*.txts should mention running autoreconf -i to bootstrap if you're building from git.

The re-org should be pulled, but autotools isnt quite ready...I was hoping (and jaromil seemed to indicate that he would work on) support for mingw cross compiling before pull (discussed after pull request was submitted). And the whole ridiculous sed action required now (4870f7d) is not really pull-ready.

NAK the mingw stuff from Matt -- it is absolutely not needed. That stuff varies from system to system, and hardcoding it into configure breaks platforms other than the one Matt's using. @Gavin: can do

@jgarzik Isnt that the point of autotools, it finds the stuff to include and link and uses that. As I said, the stuff in this pull request from my repo really should never be pulled (because of what you just said)

You provide OS-specific details to a configure script via environment variables (or occasionally, command line arguments). The script takes it from there.

That's how mingw32-configure works. It sets the configure variables correctly for the limited set of systems it knows about.

configure already has all the proper cross-compiling gadgetry built it, to compile windows apps.

source tree reorg pulled

you did not pull, you actually did a "manual merge"

i'll past here my reaction on irc:

22:59 <jaromil> oh, did you merged autotools? 23:00 <jaromil> jgarzik: i'd prefer to actually appear in the git tree with my commits. why a manual merge? 23:01 <jaromil> i did separated both commits as indicated and they were merging allright with the master the last time i've tried 23:01 <jaromil> so i don't really see the reason for a "manual merge" 23:02 <jaromil> BlueMatt: this is quite demotivating for me :( 23:03 <jaromil> it even gives a conflict on sha256 23:03 <jaromil> bha :/ i'll go to sleep

my reason to be upsed is that this confuses all the review process of this pull request so far

and hereby request you merge my original commits into master, not a "manual merge" that deletes all the documentation written in the commits.

this pull request is not yet finished, you can close this pull request if you really don't like a WIP here, i'll bring it back once completed.

thanks for your attention to details, ciao

@jaromil Your commit was merged. https://github.com/bitcoin/bitcoin/commit/84c3fb07b0b8199c7f85c5de280e7100bad0786f is your commit in the repo. Its the same pull methods used in every other pull, the merge shows up as done by jgarzik, but your commit is back in the repo by its original date.

It takes two seconds to verify that commit 84c3fb07b0b8199c7f85c5de280e7100bad0786f is in bitcoin/bitcoin.git.

Maybe three.

i was tired and almost going to sleep when i saw your merge message, apologies for my abrupt reaction. ultimately i care that all the documentation so far written in the commit messages goes into history as it has been reviewed here, else this huge movement of files will look too suspicious. i did not noticed the autotools (2nd in this branch) and thought your merge message was its rebase without the original message (the term "manual merge" is what confused me). again thanks for your attention to details and patience.

today i'll work on the second commit, the autotools build, and see if mingw32 can be integrated. In fact there is something strange still: autotools doesn't seems to honor environment flags and i want to look into it deeper, hopefully we can get rid of the hacky sed then.

ciao

seems now everything is fixed

i'm rebasing the second commit of this branch into something presentable

updated to apply on current HEAD

updated to add BlueMatt's fixes from https://github.com/TheBlueMatt/bitcoin/commit/1852b89adbaae4d3f6aea1011a7b06217c832556

I can rebase it into one commit, or leave like this.

Looking for confirmation that this builds w/ mingw32 and OSX...

It does build. i'm also asking more people to test it.

meanwhile this patch was contributed to fix build issues on BSD/OSX

https://github.com/jaromil/bitcoin/commit/086b93fff425d95b3c2e461901f22a2912cbc663

i can rebase it into this if you agree, yet i'm asking because this patch changes actual bitcoin code (just some #define conditionals), while so far this autotools pull req required nearly no change to code.

hoping we can have this pull request merged and closed soon!

I would like to see that patch as a separate commit, in this autotools pull. Makes it easier to look through, but the patch has my ACK.

OSX Broken? (10.6.7 xcode 4):

mith@dair:0:~/src/bitcoin$ port list autoconf automake miniupnpc boost wxWidgets-devel autoconf @2.68 devel/autoconf automake @1.11.1 devel/automake miniupnpc @1.5 net/miniupnpc boost @1.46.1 devel/boost wxWidgets-devel @2.9.1 graphics/wxWidgets-devel mith@dair:0:~/src/bitcoin$ autoconf configure.ac:124: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:140: error: possibly undefined macro: AM_PROG_AS configure.ac:229: error: possibly undefined macro: AM_OPTIONS_WXCONFIG configure.ac:230: error: possibly undefined macro: AM_PATH_WXCONFIG configure.ac:261: error: possibly undefined macro: AM_CONDITIONAL mith@dair:1:~/src/bitcoin$ ./configure --prefix=/usr/local configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."

Get the same thing running with autoconf 2.61 out of /usr/bin instead of macports.

Yeah, it fails on Fedora as well, missing the WX macros and similar errors to OSX

BlueMatt said use autoreconf -i; and that seems to work. If the mechanism to rebuild is not just "autoconf" it needs to be stuck into an autogen.sh / autoget.bat please.

You also seem to have reverted all my stuff that made MinGW work, its not in the current code and wont compile.

Also the resultant distclean target after autoconf/make does not remove the autoconf output.

Can that be fixed?

@jrmithdobbs: that last is standard. you want AM_MAINTAINER_MODE + "make maintainer-clean" (or "make maintainerclean", I forget)

"distclean" is only supposed to return you to the state of a freshly-unpacked dist tarball

Closing as outdated.

We do want an autotools configury of some sort, but with Qt the picture changed a bit.

So, ACK'ing the concept but NAK'ing the current pull.

On Tue, 20 Dec 2011, Jeff Garzik wrote:

Closing as outdated.

We do want an autotools configury of some sort, but with Qt the picture changed a bit.

So, ACK'ing the concept but NAK'ing the current pull.

IMHO the problem with this pull request has been waiting too much to merge it in: it will always be very hard to find someone to fix all bugs reported on all build platforms, rather than switch to something that is clean enough for everyone to read and fix in different cases.

I understand that back then when I filed the pull request the maintainance was way harder to attend since the heat on this project was higher, I hope it can now benefit as a learning experience.

ciao

jaromil, dyne.org developer, http://jaromil.dyne.org GPG: B2D9 9376 BFB2 60B7 601F 5B62 F6D3 FBD9 C2B6 8E39