From: Douglas Huff <dhuff@jrbobdobbs•org>
To: John Smith <witchspace81@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Reconsider build system change?
Date: Sat, 2 Jul 2011 12:45:02 -0500 [thread overview]
Message-ID: <65026C81-A96E-490A-90D2-794A10C2A680@jrbobdobbs.org> (raw)
In-Reply-To: <CAJNQ0stDg7qCxb8f-KjfP7k0RyM0dpHETkf==uswOzm4DstSUQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]
On Jul 2, 2011, at 12:31 PM, John Smith wrote:
> So, what about native build script generation for other platforms? autotools can only generate makefiles (with at least two intermediate code generation steps), which is quite limited.
This would be true if gmake didn't build/run basically everywhere; but, it does.
> IMO cmake is simple and elegant compared to the autotools monster. I don't see why it would be "just as bad". And I have quite some experience with both systems. Autotools is a hell to debug. cmake certainly isn't perfect, but at least it's a leap forward.
Don't get me wrong, I'm not defending autotools' design or implementation. It is; however, more ubiquitous and understood by a much wider audience.
> BTW for cmake there is "ccmake" which is even better than configure --help as it offers an interactive interface for configuration.
I would say that's actually a mark against cmake. If you need a gui to select build options because your cli doesn't have proper help output something is wrong.
If you're willing to setup and maintain a cmake build environment I wouldn't say it should be rejected outright. Speculating about it without an implementation to compare seems like a waste of time.
Especially when jaromil already has a mostly-functional autotools setup. It needs tweaking still and some changes to catch up and rebase, but it works. He also already did the tedious work to rearrange the source tree to make adding any auto-configuration tool for the build environment easy to drop in place. (Which is already merged.)
--
Douglas Huff
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 881 bytes --]
next prev parent reply other threads:[~2011-07-02 17:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-02 7:29 John Smith
2011-07-02 8:13 ` John Smith
2011-07-02 11:30 ` Matt Corallo
2011-07-02 11:49 ` John Smith
2011-07-02 14:50 ` Luke-Jr
2011-07-02 16:50 ` John Smith
2011-07-02 16:55 ` Luke-Jr
2011-07-02 17:05 ` Douglas Huff
[not found] ` <CAJNQ0su0jtaFz6abS+H24d7dqKoWkugct1yQLeVyXTgr0rkXXA@mail.gmail.com>
2011-07-02 17:31 ` John Smith
2011-07-02 17:45 ` Douglas Huff [this message]
2011-07-02 18:03 ` John Smith
2011-07-02 18:12 ` Luke-Jr
2011-07-03 10:44 ` Pieter Wuille
2011-07-07 8:49 ` Pieter Wuille
2011-07-07 16:51 ` Jeff Garzik
2011-07-07 17:40 ` John Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=65026C81-A96E-490A-90D2-794A10C2A680@jrbobdobbs.org \
--to=dhuff@jrbobdobbs$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=witchspace81@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox