autotools build

jaromil commented at 10:47 pm on April 15, 2011: contributor

just a start, needs more detections at configure, however works to build the daemon alone for now. more flags should be present on ./configure to select gui build and detect required libraries. libtool is just used to build the internal libcryptopp, but we can ship libbitcoin.so in future.

the aim of this fork is mostly that of GNUification for bitcoin codebase and process separation. code will be shared between daemon and client implementations via shared libraries.

it might look as a traumatic for now, but well think of the long term… consider no code was changed in this commit, just moved around. win32 and osx builds can be fixed to work using autotools or a parallel cmake build.

apologies for not having created a branch, i’ve pushed on my fork’s master. if that is a problem i can redo that quickly.

autotools build of bitcoind

just a start, needs more detections at configure, however works to build the daemon alone for now.
more flags should be present on ./configure to select gui build and detect required libraries.
libtool is just used to build the internal libcryptopp, but we can ship libbitcoin.so in future.

the aim of this fork is mostly that of GNUification for bitcoin codebase and process separation.
code will be shared between daemon and client implementations via shared libraries.

it might look as a traumatic for now, but well think of the long term...
win32 and osx builds can be fixed to work using autotools or a parallel cmake build.

709c9b231a

jgarzik commented at 10:51 pm on April 15, 2011: contributor

Comments:

This is duplicating work at https://github.com/jgarzik/bitcoin/tree/autotools which was mentioned on the forums at http://www.bitcoin.org/smf/index.php?topic=2772.msg82737#msg82737
You arbitrarily changed the license to GPLv3. NAK.
autotools conversion does not require a total bitcoin source tree reorg.

jaromil commented at 10:55 pm on April 15, 2011: contributor

BTW please to meet you :) i’m new on github, but not to code. i’m friend with genjix and running a bitcoin related project on http://dyndy.net see other repos i’m active on http://code.dyne.org and software on http://freshmeat.net/users/jaromil

willing to cooperate on maintainance of the C++ source package and in particular of the unix daemon, on the long term i’d like to make a shared library (libbitcoin) and uid/gid separation of daemon for better security, and maybe clear and document the API and make SWIG bindings to python.

ciao

jaromil commented at 10:57 pm on April 15, 2011: contributor

ACK. will read that
autoreconf -i does that (adds COPYING when missing) and i didn’t noticed.
true. i just went for standard code separation in src/, not sure about other approaches.

license.txt is not COPYING (required by autotools)

autoreconf -i had slipped the GPLv3 file as default, now removed.

f51506e432

jaromil commented at 11:02 pm on April 15, 2011: contributor

looked at your branch: not so much duplication since we’re both just at the beginning.

yet you might like the use of libtool in my branch :)

hack on

jgarzik commented at 11:23 pm on April 15, 2011: contributor

Well, FWIW it is unlikely that this branch will be pulled. All these are the sorts of changes we -do- want, but in general you’re wrapping way too many major changes into a single pull request. The right way to do this is with small, incremental changes, in separate pull requests that can be evaluated on their own merits, after being discussed on the forums.

For example, everyone has their own opinion on source file placement, and these changes tend to have low payback, and are low priority. See discussion in thread http://www.bitcoin.org/smf/index.php?topic=5813.0

On libbitcoin: everybody wants it, but any libbitcoin API should be informed by some applications actively using the library, i.e. real needs demonstrated in the field. So, we’re all for a libbitcoin, but we tend to be collectively wary of Grand API Designs unless you already have a lot of experience with the existing codebase and concepts :) Nothing personal.

Speaking incrementally, the first rev of autotools should just get the existing stuff working on all platforms. That means no libtool, which just adds complexity for no reason (because libbitcoin does not yet exist).

Baby steps! The first reaction of -every- programmer upon meeting bitcoin is “I want to rewrite it!” But the dev team must be conservative and keep everything running and debuggable and backwards compatible. Big pulls and major reorgs offer little payback for a large potential for breakage.

jaromil commented at 11:32 pm on April 15, 2011: contributor

i don’t understand what you mean with Grand API Designs: since bitcoin has already an API, i have no illusions of grandeur here. code reorganization needs stuff to be moved around and there are guidelines and standards for that. however i see we have different views on more things: code splitting needed as mentioned by Jim Hyslop on the forum, as well reluctance to libtool.

i don’t want to rewrite anything and actually i think the code is not that bad esp. if properly reorganized, but then is a matter of being practical.

ciao

cleanups and boost checks

it now compiles fine in autotools on unix, didn't tested other targets.

79d2741bd6

jgarzik commented at 0:15 am on April 16, 2011: contributor

There is no reluctance to libtool; it is a simple, binary decision: libbitcoin does not exist, therefore libtool should not be used. When libbitcoin exists, libtool should be used.

libtool is the wrong choice for bitcoin’s libcryptopp, because that is simply linked directly into the miner. Doing anything else – particularly moving it to a shared library – simply reduces performance for no reason.

Your Makefile.am is also broken on several operating systems, because it hardcodes the name of the various dependent libraries.

jaromil commented at 11:38 am on April 16, 2011: contributor

On Fri, 15 Apr 2011, jgarzik wrote:

libtool is the wrong choice for bitcoin’s libcryptopp, because that is simply linked directly into the miner. Doing anything else – particularly moving it to a shared library – simply reduces performance for no reason.

my use of libtool for libcryptopp is purely internal: libcryptopp is still linked statically inside the bitcoind binary (in fact I agree there is no need to make it shared) this is the recommended approach to structure autotools packages that include static libs.

Your Makefile.am is also broken on several operating systems, because it hardcodes the name of the various dependent libraries.

true, but then maybe my pull request came a bit too early, since I consider this fork just a start and I’ll complete it in the coming days. feel free to keep an eye on it and take what you like, I’ll do my best to make granular and well commented commits.

ciao

documentation subdir

just olding old makefiles and coding guidelines for now

643b4a62b9

autotool build now checks for more libraries

now using pkg-config for ssl, crypto and ghread2
also boost ldflags are used

2f4259c9ac

renamed cryptopp/config.h to settings.h

naming an header config.h besides the one generated in the root dir by autoconf is a very bad idea(tm)

9141f2c2d8

reorganized share/ directory

moved all images in share/pixmaps
moved ui and vsi files into share

7501345f69

AUTHORS file from git history

I'm not 100% sure of its correctness and should be reviewed by older
dev members. esp to distinguish people that have contributed artworks
and code and maybe specify who is busy on which part (UI, Core etc.)

79e23eca48

identify nsi file

let's write it clearly for those who don't know :P
had to ask a friend to realize...

037262c326

xpm icons back in place

they included directly in source, so they go in src/xpm

38a5845636

host architecture and OS checks at configure

that's a start to detect various supported architectures
still needs filling up needed flags, but should provide an consistent skeleton

e6ee114093

code namespace change: (int)VERSION renamed to BITCOIN_VERSION in headers.h

this change is made necessary by the fact VERSION is a reserved define
for autotools and it is actually a (char).

we could decide to keep the versioning centrally controlled in configure.ac
and then AC_DEFINE it there, however to keep changes as minimal as possible
I've just renamed it where needed.

c929baedfe

autotools selection of GUI to build

right now options are just 'wx' or 'none' (default)

this code should provide a skeleton for more GUIs in future,
making them selectable at configure, setting different flags
depending from the target host.

44841321c7

jaromil commented at 1:30 pm on April 17, 2011: contributor

so far so good: compiles on linux providing –enable-upnp and –enable-gui=wx

code itself was never modified, just moved around, with two exceptions:

9141f2c renamed cryptopp/config.h to settings.h
c929bae code namespace change: (int)VERSION renamed to BITCOIN_VERSION in headers.h so just one filename and one variable name changed.

in this branch/pull request i’ll continue hacking only on build issues and avoid touching anything into the code, in fact as it looks like now i guess nothing else in code needs changes.

ciao

upnp can now be set on or off by default

thanks luke-jr for noticing

ec40e0abad

jgarzik commented at 3:44 pm on April 17, 2011: contributor

pull requests are for finished patches, not actively hacked projects.

jgarzik closed this on Apr 17, 2011

jaromil commented at 7:29 am on April 18, 2011: contributor

sry i didn’t knew. can you specify that in the documentation? thanks.

dexX7 referenced this in commit c69245b652 on Nov 10, 2015

deadalnix referenced this in commit 841705f629 on Sep 18, 2016

rebroad referenced this in commit 381821a936 on Dec 7, 2016

deadalnix referenced this in commit ade37214ea on Dec 13, 2016

destenson referenced this in commit 1583fc2b2a on Nov 18, 2017

lateminer referenced this in commit 3b3d3b4061 on Dec 9, 2017

cryptapus referenced this in commit de3eab4919 on Aug 9, 2019

attilaaf referenced this in commit d43b646d07 on Jan 13, 2020

KolbyML referenced this in commit ebeaed402d on Aug 1, 2020

laanwj referenced this in commit d875bcc8f9 on Dec 28, 2020

cryptapus referenced this in commit f9b96c9c23 on May 3, 2021

rajarshimaitra referenced this in commit b012317ffe on Aug 5, 2021

DrahtBot locked this on Sep 8, 2021

autotools build #162