Douglas Huff [ARCHIVE] on Nostr: 📅 Original date posted:2011-07-02 🗒️ Summary of this message: Discussion on ...
📅 Original date posted:2011-07-02
🗒️ Summary of this message: Discussion on using cmake vs autotools for native build script generation. Autotools is more ubiquitous, but cmake is simpler and easier to debug.
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 881 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110702/a842180a/attachment.sig>;
🗒️ Summary of this message: Discussion on using cmake vs autotools for native build script generation. Autotools is more ubiquitous, but cmake is simpler and easier to debug.
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 881 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110702/a842180a/attachment.sig>;