回复：一些建议
原始发布页
打开来源页面查看 1 个交叉存档
引用 madhatter2 于 2009 年 12 月 12 日 06:34:21 AM 的发言
我差不多已经能在 Mac OS X 10.4.11/Intel 上编译 svn 0.2 了（我这里还有一台 PPC970 机器，所以也可以构建 PPC 版本）。窗口界面也是通过 wxwidgets 实现的原生 carbon！速度很快！(眨眼) 我不得不新建一个 makefile（当然是基于 makefile.unix 的 makefile.osx……有没有考虑过使用 autoconf？），并在 header.h 中加入一些 ifdef。我有补丁。我会继续摆弄。接下来可能会在 FreeBSD 上试试。
支持 Mac 会很好。wxWidgets 在跨平台方面确实很有价值。
请不要尝试 PPC。PPC 是大端序，而比特币是小端序，这会带来没完没了的字节序错误；如果网络里可能存在一个会交换字节序的节点，我调试网络就会更困难。反正 PPC 也正在被淘汰。
考虑过 autoconf。对于 makefile 如泥潭般复杂的大型项目，Autoconf 是必需的，但我认为我们的项目还足够小，不用它反而更合适。我宁愿尽可能长久地保持 makefile 简单。
引用
我认为把比特币拆成两个应用程序是理想的做法。一个 wxwidgets 前端（因为它基本上已经具备），再加一个绑定到控制 TCP 套接字的后端。我一直在阅读源代码，想看看把它拆开会有多难，我觉得应该相当简单。当然，还得开发一个 API。
光是想想就让我头疼。让所有 UI 后端通信都通过 TCP 连接，会使一切困难一倍。为了让列表视图控件保持更新，UI 与内部数据结构之间的数据量太大了，这是列表视图控件的工作方式所致。
我更希望有命令行控制，这样就能实现远程管理和批量自动化。
英文原文
展开英文原文
Quote from: madhatter2 on December 12, 2009, 06:34:21 AM
I almost have the svn 0.2 compiling on Mac OS X 10.4.11/Intel (I also have a PPC970 machine here as well so a PPC build would be possible as well). The windowing is native carbon too via wxwidgets! It is FAST! (Wink) I had to create a new makefile (makefile.osx; based on makefile.unix of course.. given any thought to using autoconf?) and put some ifdef's into header.h. I have patches. I will keep toying around. I might try it on FreeBSD next.
Mac support would be nice. wxWidgets really pays off for cross platform.
Please don't try PPC. PPC is big-endian and Bitcoin is little-endian, there would be endless endian bugs making it harder for me to debug the network if there's a potentially byte-swapping node out there. PPC is on its way out anyway.
Considered autoconf. Autoconf is a necessity for large projects with a quagmire makefile, but I think we're small enough that it's more optimal without it. I'd rather keep the makefile simple as long as possible.
Quote
I think that breaking bitcoin into two apps is ideal. A wxwidgets front end (since it is mostly all there) and a backend that binds to a control TCP socket. I have been reading over the source to see how hard it would be to break it apart and I think it should be fairly simple. Of course an API would have to be developed.
My head hurts just thinking about that. Funnelling all the UI backend through a TCP connection would make everything twice as hard. There's too much bandwidth between the UI and the internal data structures in order to keep the listview control updated, because of the way the listview control works.
I'd rather have command line control, that would get us remote admin and batch automation.