<unnamed>

Public Key

npub1e4lupyw4vuuhfsmt726ud69555re66pph90kwx0afpt346e9k7zsd4jafl

Profile Code

nprofile1qqsv6l7qj82kwwt5cd4l9dwxaz622puadqsmjhm8r875s4c6avjm0pgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds63gu4c

Publishing to

nostr.wine

nos.lol

relay.damus.io

Last Notes

2023-06-07 02:25:21 UTC

- reply

📅 Original date posted:2011-09-13
🗒️ Summary of this message: Incorporating NTP or removing bitcoin mining code from the client but requiring accurate system clocks for miners seems reasonable.
📝 Original message:> Fixing (2) is easier; incorporating a ntp library and/or simply
> removing the bitcoin mining code from the client but requiring pools
> and miners to have accurate-to-within-a-minute system clocks (or their
> blocks will be "discouraged") seems reasonable to me.
Incorporating NTP seems overkill. Most OSes come with NTP support integrated
these days (even XP did?), there is no excuse to not be running it,
especially on a server.
If you want to
> produce blocks that the rest of the network will accept, run ntp on
> your system.
>
Requiring it for miners sounds very reasonable.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110913/1fa29c73/attachment.html>

2023-06-07 02:24:39 UTC

- reply

📅 Original date posted:2011-09-22
🗒️ Summary of this message: A user on the Bitcoin forum likes the feature where a new address appears in their "AddressBook" automatically every time they receive Bitcoin, but others are spooked by it.
📝 Original message:2011/9/22 Martinx - ジェームズ <thiagocmartinsc at gmail.com>
> Hi everybody!!
>
> This is my first message here... I'm ThiagoCMC at bitcointalk...
>
> Well, one of the features that I like most is that, every time I receive
> some Bitcoin amount, a new address appear at my "AddressBook"automatically,
> AND, I like to track it.
>
Can I ask your rationale for this?
>From what I've noticed, most people's workflow is to create a new receiving
address for each new contact that sends them bitcoins (either for every
transaction, or they reuse the address for this person). To make sure that
the address is labeled, they create it themselves and then give out the
generated address.
They are utterly spooked by suddenly appearing unlabeled addresses, of which
they are unsure whether they are used, and which can never be removed.
I'm fine with adding it back as an option but please leave it disabled by
default...
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110922/532731f7/attachment.html>

2023-06-07 02:23:32 UTC

- reply

📅 Original date posted:2011-09-08
🗒️ Summary of this message: The Bitcoin alert system is not a cause for concern as even if the private key was compromised, the worst that could happen is spam messages.
📝 Original message:There is a lot of complaining about this alert system, but I really don't
see the problem.
As others have already said, it's just a message. Even if someone managed to
compromise the private key, the most they could do is spam graffiti messages
or try phishing. There are much worse things that could happen to the
network (in which case an alert system could come in very handy). It's just
not worth worrying about.
JS
On Thu, Sep 8, 2011 at 4:20 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
> On Thu, Sep 08, 2011 at 09:09:12AM -0700, David Perry wrote:
> > @Steve re "Who knows, it might be the only way we'll ever hear from
> Satoshi
> > again."
> >
> > That brings up a good point... Does anyone aside from Satoshi actually
> have
> > the ability to send such an alert? Should we at the very least change the
> > alert system to give such privileges to current devs and ensure that that
> if
> > the missing Mr. Satoshi has had his key compromised we don't see an
> > authoritative-looking alert come up from a malicious source?
>
> Yes, Satoshi transferred the key to Gavin when he "left". I agree we should
> keep it, btw. There have been suggestions before on this list to use the
> alert system to ask people to upgrade to recent versions of the client (eg.
> the disconnect issue 0.3.20-0.3.23 had). I feel there may come a moment
> when
> we really need to use it for that purpose.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> Doing More with Less: The Next Generation Virtual Desktop
> What are the key obstacles that have prevented many mid-market businesses
> from deploying virtual desktops? How do next-generation virtual desktops
> provide companies an easier-to-deploy, easier-to-manage and more affordable
> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110908/8fe4ee50/attachment.html>

2023-06-07 02:19:54 UTC

- reply

📅 Original date posted:2011-08-31
🗒️ Summary of this message: Qt translations can be reused for Bitcoin Core, but files need to be converted from Wx's line-based format to Qt's XML-based format. Translations can be added later.
📝 Original message:Would it be possible to port some of the existing translations?
>
Well, the strings in the core can be reused one-on-one as the _ function is
mapped to the Qt translation function.
And some of the UI texts probably can be reused as well, at least for a
rough approximation.
The files will have to be converted, as Qt uses an XML-based format whereas
Wx uses a line-based one. Also, Qt translations have a "context"
(file/object) defined whereas in Wx the "msgid" is only the English text.
Nah, nothing that a bit of Python hacking can't solve.
Though IMHO its not a huge deal if qt is merged without all the
> translations as IMHO it should be merged soon and then not the default
> release GUI until its in tree for a bit (like one release) and some
> translations can be built up.
>
Exactly... if there is some time between Qt being merged and Wx being phased
out, translations can be added. The Qt translation tool (Qt Linguist) is
user friendly enough to be used by anyone.
>
> > So IMO, it is ready to be merged.
> IMHO it should be merged right after 0.4 is pushed.
>
Sounds fine with me,
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110901/e5fb7740/attachment.html>

2023-06-07 02:14:00 UTC

- reply

📅 Original date posted:2011-08-10
🗒️ Summary of this message: Gavin Andresen is against splitting off the "send commands to a running bitcoin" as it would force developers to tweak their code.
📝 Original message:On Wed, Aug 10, 2011 at 4:49 PM, Gavin Andresen <gavinandresen at gmail.com>wrote:
> RE: splitting off the "send commands to a running bitcoin" :
>
> I'm mildly against it. It would be less confusing for newbies, at the
> cost of forcing everybody who has already written backup scripts or
> other interact-with-running-bitcoin tools to tweak their code. The
> coding will be easy, but do you really want to spend the time to
> answer all the "I installed Bitcoin X.Y and now my backup script
> doesn't work" questions and modify the wiki pages and ...
>
As the project is still in "experimental" phase I suppose people can expect
changes like this? And the change is pretty much trivial, and it makes sense
for a future direction (UI<->Wallet in separate processes for security
concerns).
To be honest I feel a bit like every change that I (and I've also heard this
from others) propose is shot down, no matter how well formulated. This is
actively discouraging developers from joining this project.
Of course it makes sense to be a careful, but the project is not on life
support is it? Satoshi did a great job making the program, but his work was
not perfect, and it makes sense to look ahead a bit.
I think it would be better to switch to two branches, like most other open
source projects I've worked with:
0.3.x -> small, compatible changes, bugfixes, like now
0.4.x -> trunk, more impactful changes, refactorings, eventual major release
Both will obviously be fully compatible on the P2P-level.
> I'd rather that time be spent working on any remaining build issues so
> we can switch to bitcoin-qt. I don't care if it is autotools or qmake
> or QT creator, I just care that it works on Windows and Linux under
> gitian and has clear instructions so I can build it on my Mac.
>
I could do the Gitian stuff but not the Mac instructions, as I don't have a
Mac...
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110810/199e8a3e/attachment.html>

2023-06-07 02:13:44 UTC

- reply

📅 Original date posted:2011-08-10
🗒️ Summary of this message: The proposal suggests separating the headless daemon from the UI executable, making it possible to build the command line RPC client without building the server or UI.
📝 Original message:On Wed, Aug 10, 2011 at 10:14 AM, Matt Corallo <bitcoin-list at bluematt.me>wrote:
> I would argue its less clear for the user. Instead of opening either
> bitcoind or bitcoin to get RPC or GUI, now you have to open bitcoin and
> bitcoind or bitcoincl and bitcoind. Now, obviously bitcoin and
> bitcoincl can open bitcoind for you, but I think adding more executables
> complicates things for little clear advantage.
>
UI would obviously still have RPC functionality with -server. I don't mean
dropping that. The UI links both the UI and the network code (for now, until
this is separated out and the preferred UI<->core communication method is
through RPC).
I just mean that the *headless* daemon is separate from the UI executable,
which is the case for any other sane client/server-based program in
existence, from bittorrent nodes to game servers.
It would also make it possible to build the command line RPC client
(bitcoin-cl) *without* building the server or UI. Useful if you want to
remotely control a Bitcoin daemon but not want to build it locally.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110810/891241ae/attachment.html>

2023-06-07 02:13:38 UTC

- reply

📅 Original date posted:2011-08-10
🗒️ Summary of this message: Proposal to split Bitcoin client into three separate executables: bitcoind (daemon), bitcoin(-qt) (GUI), and bitcoincl (RPC command line). Advantages include clearer user experience and simplified main functions.
📝 Original message:All,
In the current mainline client everything is lugged into one executable
(with an optional daemon-only one). I think this is a bad idea for various
reasons, and would propose something like:
- bitcoind: bitcoin daemon
- bitcoin(-qt): bitcoin GUI executable
- bitcoincl: bitcoin RPC command line
By default, all three would be built. In non-GUI mode, only bitcoind and
bitcoincl are built (the names are obviously open for discussion).
Advantages:
- It is more clear to the user. One command, one function.
- It simplifies the main functions.
- The UI would no longer double-function as daemon. It is a waste of
memory to link the UI libs if you only want to run a background process.
- The UI and daemon would no longer double-function as RPC call. Why load
the code for UI and network if you just want to send a single command over
JSONRPC? This would also prevent accidentally launching the daemon/UI
locally if you just want to send a command and forget to give an argument.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110810/dc4f6bdd/attachment.html>

2023-06-07 02:11:46 UTC

- reply

📅 Original date posted:2011-08-05
🗒️ Summary of this message: Re-broadcasting Bitcoin transactions could potentially allow for the identification of both the sender and recipient's IP addresses.
📝 Original message:> 3) The recipient re-broadcasts transactions (is Theymos right here?),
> allowing both the sender and recipient to be found
>
Hm this would potentially allow getting the IP for any recipient Bitcoin
address, given that a client with the private key connects to the network
once in a while.
Send them a transaction that is guaranteed to not be written into a block by
a miner, then monitor who rebroadcasts it over a few days/weeks.
I guess this could also be used to find out who has the stolen coins.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110805/26b73de3/attachment.html>

2023-06-07 02:11:43 UTC

- reply

📅 Original date posted:2011-08-05
🗒️ Summary of this message: Developers should focus on making Bitcoin transactions secure and fast, rather than on anonymity. Using Tor/I2P is a better option for anonymity.
📝 Original message:On Fri, Aug 5, 2011 at 12:58 PM, Christian Decker <
decker.christian at gmail.com> wrote:
> While I do think that anonymity (or pseudonymity) is a nice feature, I
> don't think it deserves the full focus of the developers. The core of the
> protocol is about making transactions in a secure and fast way, not allowing
> everybody to be anonymous, whether they want to or not. TOR already is a
> good options for those that want to stay anonymous, and there is no need to
> pull support into the main client, if only a few will use it. I think very
> few of the developers actually claimed that Bitcoin is anonymous, and has
> never been a big advertising point from the "official" side of Bitcoin,
> network analysis has been always known to break anonymity.
>
Yes. Optionally layering Bitcoin over Tor/I2P is a much better option than
trying to replicate an onion network in Bitcoin itself. For one, traffic
analysis is much more difficult if your onion routing network contains
multiple kinds of traffic. Also it would complicate the core algorithm and
waste developer time. Doing anonymity *right* is very hard. So let's leave
it to the Tor/I2P people that know what they're doing.
>
> I see no need for action from the developer side.
>
Except the part about making the client/network more resistant against DDoS.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110805/3d4fc4a5/attachment.html>

2023-06-07 02:11:31 UTC

- reply

📅 Original date posted:2011-08-05
🗒️ Summary of this message: Bitcoin network is facing security testing with problems including DDoS possibility, transaction broadcasting, and re-broadcasting. UDP packets with spoofed sender addresses are suggested.
📝 Original message:On Fri, Aug 5, 2011 at 1:16 AM, Gavin Andresen <gavinandresen at gmail.com>wrote:
>
> ... so it is a de-anonymize-via IP address not de-anonymize-via Bitcoin
> address. And might go partway to explaining why we're having trouble with
> network connectivity...
>
Well it's good that the bitcoin network is seeing some security testing.
So I understand that we have a combination of problems at the moment:
1) A DDoS possibility (if this is really the cause of the network
connectivity problems)
2) An attacker can figure out which node first broadcasted a transaction, by
connecting to the entire network or having everyone connect to his node(s)
3) The recipient re-broadcasts transactions (is Theymos right here?),
allowing both the sender and recipient to be found
Drawok's suggestion about using UDP packets with spoofed sender addresses is
interesting, as UDP has another advantage; you can open up an "inbound" UDP
port on almost any NAT router without any UPNP magic: just send out an UDP
packet, the router will wait a certain time for answers (on a mapped port
number) and relay these back.
It also has some potential issues; the client needs special privileges to
spoof sender addresses, and some ISPs might filter out packets with
non-matching sender addriess (unsure how common this is).
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110805/1c336328/attachment.html>

2023-06-07 02:11:18 UTC

- reply

📅 Original date posted:2011-08-04
🗒️ Summary of this message: Dan Kaminsky discussed bitcoin security vulnerabilities at BH 2011, including a tool called "blitcoin" that unmasks both sides of a transaction. More information is needed.
📝 Original message:L.S.
Some bitcoin "security vulnerabilities" have been discussed by Dan Kaminsky
at BH 2011, there is one article about this dated yesterday:
http://searchsecurity.techtarget.com/news/2240039221/Black-Hat-2011-Dan-Kaminsky-reveals-network-security-research-topics
The article is very unspecific though. They talk about a tool called
"blitcoin" that "unmasks" both sides of a bitcoin transaction. A google
search also turned up nothing, except some misspellings.
Does anyone have more information?
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110804/3023ad09/attachment.html>

2023-06-07 02:08:42 UTC

- reply

📅 Original date posted:2011-07-27
🗒️ Summary of this message: Offering bounties for developers to fix bugs in Bitcoin software could increase its value, but should be a symbolic gesture rather than a full-time salary.
📝 Original message:On Wed, Jul 27, 2011 at 4:07 PM, Rick Wesson
<rick at support-intelligence.com>wrote:
> personally, if the software works better (less bugs) then btc will be more
> valuable. offering bounty is orthorginal to finding the right technical lead
> that will hurd the effort.
>
> put a bounty (salary) on the person to lead the effort, not the bugs
>
Bounties would be much less than a developer salary. The idea is not to pay
for people full time, but it would be more of a symbolic gesture to attract
developers and get them some coins. People with coins are also more
motivated to make the project more valuable, otherwise you have a "tragedy
of the commons" problem.
Not that I don't agree Gavin with getting a salary but that's a completely
independent issue :)
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110727/339660fb/attachment.html>

2023-06-07 02:08:29 UTC

- reply

📅 Original date posted:2011-07-27
🗒️ Summary of this message: The discussion is about whether to use GitHub for bug tracking or set up a separate bug tracker, with a suggestion to create a list of bounties on a separate site.
📝 Original message:On Wed, Jul 27, 2011 at 2:42 PM, Joel Joonatan Kaartinen <joel.kaartine
Although, if GitHub can't support the feature, it could be an argument
> for setting up a bug tracker unrelated to GitHub.
>
Well if signing up with github is such a big problem we could make a list of
bounties on our own site with a trivial web application, and link from there
to github issues (if neccesary) for a description. It really doesn't matter
how it's implemented. I think it is useless to discuss technical details or
GitHub TOS right now, let's discuss the merit of ideas...
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110727/2552af74/attachment.html>

2023-06-07 02:08:19 UTC

- reply

📅 Original date posted:2011-07-27
🗒️ Summary of this message: A suggestion to add a way for anyone to add to the bounty attached to a bug on the bug tracker and a listing page for bugs with their bounties. A roadmap could also help.
📝 Original message:On Wed, Jul 27, 2011 at 11:14 AM, Joel Joonatan Kaartinen <
joel.kaartinen at gmail.com> wrote:
> Perhaps even add a way for anyone add to the bounty attached to a bug on
> the bug tracker? Also, a listing page for bugs with their bounties might
> be nice too.
>
Good idea. I'm not sure if the github bug tracker supports extension
attributes, but it'd be a great place to add it. Also, people can let know
that they're already working on a feature using a comment, to prevent double
work.
The biggest problem will be organizational, in getting the BTC together for
bounties; only a high profile member such as Gavin will have enough trust to
ask for support. Or maybe there's something left in the faucet? :-)
Unrelated: what also might help is publishing a roadmap. Plan a few "bug fix
only" releases before scheduling addition of new features. It's also helpful
for people that wonder that direction the project is going in...
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110727/b57f8cf1/attachment.html>

2023-06-07 02:08:13 UTC

- reply

📅 Original date posted:2011-07-27
🗒️ Summary of this message: Gavin Andresen asks for advice on how to encourage more bug-fixing and testing of existing functionality instead of adding more features. Suggestions include offering BTC bounties for fixing bugs and finding security holes.
📝 Original message:On Wed, Jul 27, 2011 at 1:31 AM, Gavin Andresen <gavinandresen at gmail.com>wrote:
> Anybody have advice on how to encourage more bug-fixing and testing of
> existing functionality instead of yet-more-features?
Make a list of bugs. Offer BTC bounties for fixing each one according to how
serious/difficult it is. They don't have to be high, just a few BTC. It'll
also help people get interested in the project and *current* source base
(instead of wanting to implement Yet Another Incomplete Client from
scratch).
Or we could do the same as the mozilla/chrome projects, offer bounties for
finding new security holes and serious bugs.
A policy like "that spiffy new feature you want won't be considered until
you've helped close some open bugs" won't work. This is open source, people
can just make their own fork with the spiffy new feature without fixing any
bugs.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110727/6d2d3f7d/attachment.html>

2023-06-07 02:01:46 UTC

- reply

📅 Original date posted:2011-07-07
🗒️ Summary of this message: A developer is willing to write a cmake configuration for Bitcoin, but currently sticking with qmake as it works well for a small project.
📝 Original message:Hello Pieter,
Other opinions? Someone actually interested in writing a cmake configuration
> for bitcoin?
>
I'm willing to do it, but the priority is not that high.
I'm currently sticking with qmake, as apart from boost library name
auto-detection, I had no problems with it and it works well enough for a
relatively small project such as bitcoin.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110707/61f47a76/attachment.html>

2023-06-07 02:01:27 UTC

- reply

📅 Original date posted:2011-07-02
🗒️ Summary of this message: A discussion about the use of autotools versus cmake as a build system for a project, with concerns raised about cmake not following the standard build procedure.
📝 Original message:On Sat, Jul 2, 2011 at 2:50 PM, Luke-Jr <luke at dashjr.org> wrote:
> On Saturday, July 02, 2011 3:29:04 AM John Smith wrote:
> > Why again did we choose for autotools as future build system instead of
> > cmake?
>
> I don't really care much either way, but cmake doesn't follow the standard
> build procedure (./configure && make && make install), though I imagine
> ./configure could be emulated with some script.
>
It would change the sequence to
cmake . && make && make install
So a shell script named 'configure' that starts 'cmake .' is the most easy
case :-) Probably it'd also need to pass through some command line args, for
example --prefix.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110702/e5aef2ef/attachment.html>

2023-06-07 02:01:21 UTC

- reply

📅 Original date posted:2011-07-02
🗒️ Summary of this message: CMake is a standard build system used by many projects and available in most distros, making it easy to install.
📝 Original message:On Sat, Jul 2, 2011 at 11:30 AM, Matt Corallo <bitcoin-list at bluematt.me>wrote:
> would be up to whoever writes the build system. However, autotools is
> more standard than CMake, and since its a shell script, you dont have to
> install CMake which doesnt come standard on almost any distros (AFAIK).
>
CMake is also very standard, used by many projects, and is available in many
distros.
For debians it's as simple as apt-get install cmake, which is not a big
problem as you need to install the other dependencies (such as boost) as
well to build.
Fedora/redhat also seems to have the package 'cmake'. I don't think there is
any modern distro that doesn't have it as a package.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110702/64f653a8/attachment.html>

2023-06-07 02:01:14 UTC

- reply

📅 Original date posted:2011-07-02
🗒️ Summary of this message: CMake is suggested as a better build system than autotools due to its cross-platform support, clearer syntax, and faster speed.
📝 Original message:Also important: it supports cross compiling:
http://www.cmake.org/Wiki/CMake_Cross_Compiling
JS
On Sat, Jul 2, 2011 at 7:29 AM, John Smith <witchspace81 at gmail.com> wrote:
> Hello,
>
> Why again did we choose for autotools as future build system instead of
> cmake?
>
> - CMake generates native build scripts for Make (all platforms), XCode,
> Visual Studio. Autoconf only does Make.
>
> - CMake has a clearer syntax, m4/autotools is very convoluted
>
> - CMake is very fast
>
> - CMake is supported natively in Qt Creator in the QT SDK, and is used by
> many other KDE/QT as well as other open source applications. Many people
> discourage the use of autotools for new projects.
>
> A CMake build system for bitcoin is already integrated into rpcminer,
> available here:
>
> http://luke.dashjr.org/programs/bitcoin/w/puddinpop-bitcoin-pool.git/tree
>
> JS
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110702/9df8688f/attachment.html>

2023-06-07 02:01:11 UTC

- reply

📅 Original date posted:2011-07-02
🗒️ Summary of this message: CMake is a better choice than autotools as a build system due to its ability to generate native build scripts for multiple platforms, clearer syntax, and faster speed.
📝 Original message:Hello,
Why again did we choose for autotools as future build system instead of
cmake?
- CMake generates native build scripts for Make (all platforms), XCode,
Visual Studio. Autoconf only does Make.
- CMake has a clearer syntax, m4/autotools is very convoluted
- CMake is very fast
- CMake is supported natively in Qt Creator in the QT SDK, and is used by
many other KDE/QT as well as other open source applications. Many people
discourage the use of autotools for new projects.
A CMake build system for bitcoin is already integrated into rpcminer,
available here:
http://luke.dashjr.org/programs/bitcoin/w/puddinpop-bitcoin-pool.git/tree
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110702/71e0983d/attachment.html>

2023-06-07 01:21:33 UTC

- reply

📅 Original date posted:2011-06-17
🗒️ Summary of this message: Developer requests information on when the autotools build system will be included to support multiple GUIs in the upcoming 0.4.0 release.
📝 Original message:Hello,
I think my Qt GUI is pretty much ready for merging. I've been using it for a
while and all functionality works.
What is the current roadmap for including the autotools build system, so
that it will be possible to support multiple GUIs? 0.4.0?
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110617/f52640b9/attachment.html>