autotools build #162
autotools build #162
Conversation
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.
|
Comments:
|
|
BTW please to meet you :) i'm new on github, but not to code. willing to cooperate on maintainance of the C++ source package and in particular of the unix daemon, ciao |
|
autoreconf -i had slipped the GPLv3 file as default, now removed.
|
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 |
|
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. |
|
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 |
it now compiles fine in autotools on unix, didn't tested other targets.
|
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. |
|
On Fri, 15 Apr 2011, jgarzik wrote:
my use of libtool for libcryptopp is purely internal: libcryptopp is
true, but then maybe my pull request came a bit too early, since I ciao |
just olding old makefiles and coding guidelines for now
now using pkg-config for ssl, crypto and ghread2 also boost ldflags are used
naming an header config.h besides the one generated in the root dir by autoconf is a very bad idea(tm)
moved all images in share/pixmaps moved ui and vsi files into share
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.)
let's write it clearly for those who don't know :P had to ask a friend to realize...
they included directly in source, so they go in src/xpm
that's a start to detect various supported architectures still needs filling up needed flags, but should provide an consistent skeleton
…ders.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.
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.
|
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:
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 |
thanks luke-jr for noticing
|
pull requests are for finished patches, not actively hacked projects. |
|
sry i didn't knew. can you specify that in the documentation? thanks. |
3154ea6 Bump version to 0.0.10.0-rc1 (dexX7)
Make C++11 the new required minimum
Compact blocks (BIP152)
Remove vfReachable and modify IsReachable to only use vfLimited.
GitHub-Pull: bitcoin#162 Rebased-From: a8c449e
getbestblockhash and time as epoch for ledger
define a sat as 1e-8XMY
PHR-7 adding ask to unlock dialog in create proposal button
e262a19 gui: display network in peer details (Jon Atack) 9136953 gui: rename peer tab column headers, initialize in .h (Hennadii Stepanov) 05c08c6 gui: add network column in peers tab/window (Jon Atack) e0e5506 gui: fix broken doxygen formatting in src/qt/guiutil.h (Jon Atack) 0d5613f gui: create GUIUtil::NetworkToQString() utility function (Jon Atack) af9103c net, rpc: change CNodeStats::m_network from string to Network (Jon Atack) Pull request description: and rename peers window column headers from NodeId and Node/Service to Peer Id and Address.  ACKs for top commit: laanwj: ACK e262a19 Tree-SHA512: 709c2a805c109c2dd033aca7b6b6dc94ebe2ce7a0168c71249e1e661c9c57d1f1c781a5b9ccf3b776bedeb83ae2fb5c505637337c45b1eb9a418cb1693a89761
0d7f3f6 Correcting the instance where the prior opcode is a OP_NAME*, but the referenced name is shorter than 5 bytes. As in issue#140, this converts the asm decode into interpreting the name value as an integer by accident. (Midnight Magic) Pull request description: Very short names should still be decoded as strings and not numbers when they are part of a name script. This is a rebased and squashed version of bitcoin#162, fixing bitcoin#140. Tree-SHA512: 904518a1f4492356f97d5cd6ca983f4ffb7a41db784d5f169d537bd37a57bfcadae470bf15f6938732806f12ef37895dba6fd5c765154206032350431dc17de3
add missing underscore
2 participants
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.