Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.83.47 as permitted sender)
	client-ip=74.125.83.47; envelope-from=witchspace81@gmail.com;
	helo=mail-gw0-f47.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAJNQ0ssWeU2vgR8XmCyGiZ3UHPv=zjLZEKVM=gqP0ozSC7Wmiw@mail.gmail.com>
References: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com>
	<1312971289.3253.6.camel@BMThinkPad.lan.bluematt.me>
	<20110810104316.GA30749@ulyssis.org>
	<CAJNQ0ssWeU2vgR8XmCyGiZ3UHPv=zjLZEKVM=gqP0ozSC7Wmiw@mail.gmail.com>
Date: Wed, 10 Aug 2011 13:18:38 +0000
Message-ID: <CAJNQ0stkZ=iBCJA7E5+LZToe2MjEJnhqWoiUtLcqTGPygSikiA@mail.gmail.com>
From: John Smith <witchspace81@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=000e0cd2537cb0ca7f04aa2684a0
Subject: [Bitcoin-development]  Change to multiple executables?
Precedence: list

--000e0cd2537cb0ca7f04aa2684a0
Content-Type: text/plain; charset=ISO-8859-1

> I do agree about splitting off bitcoincl - it's kinda confusing now how
> the client behaves as a rpc daemon or UI when no RPC command-line
> parameters are present, and as a command-line client otherwise.
>
> I am less sure UI and RPC should be split (though being able to select
> both independently from eachother at compile time would be nice). I
> often run the UI and switch to RPC calls to inspect some details.
> Not sure how common this usage pattern is, though.
>

No no no I never stated that the UI should no longer support RPC. If you
want the UI, with RPC, you can still run the UI executable with -server.
There are many usecases in which you want to access the UI bitcoin client
using RPC...

I only meant that it would also build the *headless* daemon by default, as
separate "bitcoind" executable. So you cannot run the UI exectuable as
headless server anymore. The -daemon option would go away. It would make the
setup a lot easier: The UI can connect to  X and display a splash screen
immediately without first looking at the command line arguments, whereas the
headless daemon can ignore all that stuff and get straight to work.


> > If you are suggesting this so that bitcoin-qt can be distributed being
> > built off of bitcoind, I would say go ahead and pull-request bitcoin-qt.
> > I'm of the opinion that it should be merged whether we have autotools or
> > not (we already have 5 makefiles, whats a few more options in those?)
> > and jgarzik seemed to indicate that he would agree (Gavin?, sipa?
> > tcatm?).
>

> That said, it seems bitcoin-qt is mature enough to replace wxbitcoin
> to me, and would definitely like to see it in mainline. How streamlined
> is the process of building bitcoin-qt on windows and osx? Maybe we can
> switch everything to qmake (for now, as long as no maintained autotools
> is present)?
>

It's easy on windows:  just install Qt Creator (comes with the Qt SDK),
install the extra dependencies (build instructions are in README.rst), and
hit build.

On MacOSX I'm not sure.  I think it's similar, as a few people built it for
MacOSX and contributed settings for the .pro file...

It can build the GUI fine for every platform, however it can only build the
GUI, not the headless daemon or the command line client. You'd still need
old fashioned makefiles for those.

Cmake or autotools would be better, especially as those are intelligent
enough to auto-detect the name of libraries such as boost, and detect
presence of optional dependencies (miniupnp).

JS

--000e0cd2537cb0ca7f04aa2684a0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>
<div class=3D"gmail_quote"><div class=3D"gmail_quote"><div class=3D"im"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">I do agree about splitting off bitcoincl - it&#=
39;s kinda confusing now how<br>

the client behaves as a rpc daemon or UI when no RPC command-line<br>
parameters are present, and as a command-line client otherwise.<br>
<br>
I am less sure UI and RPC should be split (though being able to select<br>
both independently from eachother at compile time would be nice). I<br>
often run the UI and switch to RPC calls to inspect some details.<br>
Not sure how common this usage pattern is, though.<br></blockquote></div><d=
iv><br>No no no I never stated that the UI should no longer support RPC. If=
 you want the UI, with RPC, you can still run the UI executable with -serve=
r. There are many usecases in which you want to access the UI bitcoin clien=
t using RPC...<br>

<br>I only meant that it would also build the *headless* daemon by default,=
 as separate &quot;bitcoind&quot; executable. So you cannot run the UI exec=
tuable as headless server anymore. The -daemon option would go away. It wou=
ld make the setup a lot easier: The UI can connect to=A0 X and display a sp=
lash screen immediately without first looking at the command line arguments=
, whereas the headless daemon can ignore all that stuff and get straight to=
 work.<br>

<br></div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:=
1ex">
<div><br>
&gt; If you are suggesting this so that bitcoin-qt can be distributed being=
<br>
&gt; built off of bitcoind, I would say go ahead and pull-request bitcoin-q=
t.<br>
&gt; I&#39;m of the opinion that it should be merged whether we have autoto=
ols or<br>
&gt; not (we already have 5 makefiles, whats a few more options in those?)<=
br>
&gt; and jgarzik seemed to indicate that he would agree (Gavin?, sipa?<br>
&gt; tcatm?). <br></div></blockquote></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204=
);padding-left:1ex">
<br><div class=3D"im">
That said, it seems bitcoin-qt is mature enough to replace wxbitcoin<br>
to me, and would definitely like to see it in mainline. How streamlined<br>
is the process of building bitcoin-qt on windows and osx? Maybe we can<br>
switch everything to qmake (for now, as long as no maintained autotools<br>
is present)?<br></div></blockquote><div><br>It&#39;s easy on windows:=A0 ju=
st install Qt Creator (comes with the Qt SDK), install the extra dependenci=
es (build instructions are in README.rst), and hit build.<br><br>On MacOSX =
I&#39;m not sure.=A0 I think it&#39;s similar, as a few people built it for=
 MacOSX and contributed settings for the .pro file...<br>

<br>It can build the GUI fine for every platform, however it can only build=
 the GUI, not the headless daemon or the command line client. You&#39;d sti=
ll need old fashioned makefiles for those.<br><br>Cmake or autotools would =
be better, especially as those are intelligent enough to auto-detect the na=
me of libraries such as boost, and detect presence of optional dependencies=
 (miniupnp).<br>
<font color=3D"#888888">
<br>JS<br><br></font></div></div>
</div><br>

--000e0cd2537cb0ca7f04aa2684a0--