Skip to content

Conversation

jaromil
Copy link
Contributor

@jaromil jaromil commented Apr 23, 2011

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

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/bitcoin@84c3fb0

    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

@sipa
Copy link
Member

sipa commented Apr 23, 2011

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.

@jaromil
Copy link
Contributor Author

jaromil commented Apr 24, 2011

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

@TheBlueMatt
Copy link
Contributor

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?

@jaromil
Copy link
Contributor Author

jaromil commented Apr 25, 2011

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

@jaromil
Copy link
Contributor Author

jaromil commented Apr 25, 2011

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.

@jaromil
Copy link
Contributor Author

jaromil commented Apr 25, 2011

Pull request is now rebased to an acceptable state.

@jgarzik
Copy link
Contributor

jgarzik commented May 5, 2011

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

@gavinandresen
Copy link
Contributor

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.

@TheBlueMatt
Copy link
Contributor

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.

@jgarzik
Copy link
Contributor

jgarzik commented May 9, 2011

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

@TheBlueMatt
Copy link
Contributor

@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)

@jgarzik
Copy link
Contributor

jgarzik commented May 9, 2011

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.

@jgarzik
Copy link
Contributor

jgarzik commented May 9, 2011

source tree reorg pulled

@jaromil
Copy link
Contributor Author

jaromil commented May 9, 2011

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

i'll past here my reaction on irc:

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

@TheBlueMatt
Copy link
Contributor

@jaromil Your commit was merged. 84c3fb0 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.

@jgarzik
Copy link
Contributor

jgarzik commented May 9, 2011

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

Maybe three.

@jaromil
Copy link
Contributor Author

jaromil commented May 10, 2011

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

@jaromil
Copy link
Contributor Author

jaromil commented May 11, 2011

seems now everything is fixed

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

@jaromil
Copy link
Contributor Author

jaromil commented May 30, 2011

updated to apply on current HEAD

updated to add BlueMatt's fixes from
TheBlueMatt@1852b89

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

@jgarzik
Copy link
Contributor

jgarzik commented Jun 20, 2011

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

@jaromil
Copy link
Contributor Author

jaromil commented Jun 21, 2011

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

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

jaromil@086b93f

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!

@TheBlueMatt
Copy link
Contributor

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.

jaromil and others added 2 commits June 22, 2011 15:50
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.

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.

To start first generate configure using 'autoreconf -i'
then the usual ./configure && make

Use make V=1 for verbose compulation output.

Configure flags
---------------

Besides the usual flags provided by autotools, the following are
notable:

 --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) and gconv the GNU
 		    coverage tool

 --with-wxdir=PATH Use uninstalled version of wxWidgets in PATH

 --with-wx-prefix=PREFIX Prefix where wxWidgets is installed

 --with-boost and more boost build configuration
 --with-boost-lib (use both boost flags to activate this option)

Build targets
--------------------

Please note also 'make distcheck' is working to facilitate stable
releases distribution.

Build was tested on Debian, Ubuntu, Apple OSX 10.5, CYGWIN win32 and
Cross-compiled using MinGW32 on GNU/Linux
…and MSG_NOSIGNAL

* switched to using HAVE_SO_NOSIGPIPE and HAVE_MSG_NOSIGNAL provided by autotools
@jrmithdobbs
Copy link
Contributor

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 "." "./.." "./../.."

@jrmithdobbs
Copy link
Contributor

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

@jgarzik
Copy link
Contributor

jgarzik commented Jun 27, 2011

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

@jrmithdobbs
Copy link
Contributor

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.

@TheBlueMatt
Copy link
Contributor

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

@jrmithdobbs
Copy link
Contributor

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

Can that be fixed?

@jgarzik
Copy link
Contributor

jgarzik commented Jun 27, 2011

@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

@ghost ghost assigned alexwaters Oct 20, 2011
@jgarzik
Copy link
Contributor

jgarzik commented Dec 20, 2011

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.

@jgarzik jgarzik closed this Dec 20, 2011
@jaromil
Copy link
Contributor Author

jaromil commented Dec 22, 2011

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

dexX7 pushed a commit to dexX7/bitcoin that referenced this pull request Oct 23, 2014
dexX7 added a commit to dexX7/bitcoin that referenced this pull request Aug 17, 2015
e7eb805 Update seed blocks to 370000 (zathras-crypto)
glv2 referenced this pull request in glv2/peercoin Mar 21, 2016
deadalnix pushed a commit to deadalnix/bitcoin that referenced this pull request Dec 13, 2016
classesjack pushed a commit to classesjack/bitcoin that referenced this pull request Jan 2, 2018
…ntract-txs

Fix problems with spending zero-confirmation transactions to create/call contracts
cryptapus added a commit to cryptapus/bitcoin that referenced this pull request Feb 28, 2020
laanwj added a commit that referenced this pull request Jan 27, 2021
79a2576 doc: update ConnectionType Doxygen documentation (Jon Atack)
f3153dc gui: improve markup handling of connection type tooltip (Jon Atack)
4f09615 gui: return inbound {full, block} relay type in peer details (Jon Atack)

Pull request description:

  Three follow-ups to #163:
  - return relay type for inbound peers
  - improve markup handling in the tooltip to facilitate translations
  - update ConnectionType doxygen documentation

  ![Screenshot from 2021-01-11 08-37-44](https://user-images.githubusercontent.com/2415484/104156081-50e69300-53e0-11eb-9b0f-880cb5626d68.png)

ACKs for top commit:
  hebasto:
    re-ACK 79a2576, only suggested changes since my [previous](bitcoin-core/gui#180 (review)) review.
  jarolrod:
    ACK 79a2576, tested on macOS 11.1 with Qt 5.15.2
  laanwj:
    Code review ACK 79a2576

Tree-SHA512: 4a8d8f8bfbaefd68e8d1bf3b20d29e4a8e8cfe97b2f8d59d3a4c338a50b61de0a67d97bd8646c04bd5df5a9679c4954b9b46e7cba24bb89f4d0e44e94cf9d66c
rajarshimaitra pushed a commit to rajarshimaitra/bitcoin that referenced this pull request Aug 5, 2021
- comma must follow "additionally" and "however" as they are introductory words or phrases
- same for "last but not least", comma missing
- "nothing else than", not perfect English; better "nothing but" 
- "get most use", not perfect English; better "get more benefits"
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants