1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <witchspace81@gmail.com>) id 1Qr8gG-0002Yz-Lt
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Aug 2011 13:18:44 +0000
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;
Received: from mail-gw0-f47.google.com ([74.125.83.47])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1Qr8gF-0007RL-Tk
for bitcoin-development@lists.sourceforge.net;
Wed, 10 Aug 2011 13:18:44 +0000
Received: by gwb11 with SMTP id 11so806963gwb.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 10 Aug 2011 06:18:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.8.10 with SMTP id 10mr8193314ybh.60.1312982318500; Wed, 10
Aug 2011 06:18:38 -0700 (PDT)
Received: by 10.150.52.5 with HTTP; Wed, 10 Aug 2011 06:18:38 -0700 (PDT)
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
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(witchspace81[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (witchspace81[at]gmail.com)
0.0 T_FRT_PROFILE1 BODY: ReplaceTags: Profile (1)
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
-0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Qr8gF-0007RL-Tk
Subject: [Bitcoin-development] Change to multiple executables?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 10 Aug 2011 13:18:44 -0000
--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 "bitcoind" 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>
> If you are suggesting this so that bitcoin-qt can be distributed being=
<br>
> built off of bitcoind, I would say go ahead and pull-request bitcoin-q=
t.<br>
> I'm of the opinion that it should be merged whether we have autoto=
ols or<br>
> not (we already have 5 makefiles, whats a few more options in those?)<=
br>
> and jgarzik seemed to indicate that he would agree (Gavin?, sipa?<br>
> 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'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'm not sure.=A0 I think it'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'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--
|
