Comment Re:Timely (Score 2) 103
Of course, it's also possible that I'm getting old.
Of course, it's also possible that I'm getting old.
No,
No? From the message:
at this point in time I'd advocate against Mozilla, Libreoffice, XFCE or LXDE to switch to GTK 3. They value their independence from GNOME too much.
My comment didn't contain any statement of value about GTK3 or GNOME, so I can't understand the rest of your message about being dickish, lazy, Enlightenment looking bad, me forcing other people to solve my problems, and so on. Perhaps you're talking in general about the attitude you perceive here on slashdot towards GNOME 3, but then if you do that in reply to a message of mine, you make it look like I said any of the stuff you're talking about. Which is not the case.
Which is why at this point in time I'd advocate against Mozilla, Libreoffice, XFCE or LXDE to switch to GTK 3. They value their independence from GNOME too much.
What's the difference between "I advocate against projects that value their independence from GNOME to use GTK 3" and "I don't want you to use GTK 3 outside of GNOME"?
(But then again I wouldn't believe that home routers could be sold with an internet-facing backdoor open by default in their stock firmware, until that happened.)
(cmake is probably the best, since it's more portable than autoconf).
As a user of autoconfed packages, I find autoconf superior to cmake. Packages built with autoconf have standardized mechanisms for uninstallation (a cmake package may generate an install-manifest file, an uninstall target, or none of the two), to specify where to put documentation, for cross-compilation, and to fine-tune the build and the installation. With cmake, I can't even tell the package where to install libraries (most packages will allow you to do it, but each package has a different standard about the way to be told); with autoconf, I can even specify a sed to be run on the name of the installed binaries (useful if different packages provide different implementations of the same binary) and still have the installed package work. Also, with cmake packages building both static and dynamic libraries at the same time is usually impossible.
Moreover, modern autoconf scripts are (relatively) easy to debug and patch when they don't work; cmake scripts are more scattered and they're written in an obscure mainframish language.
That said, I imagine that using autoconf on non-posix systems might be less funny.
Anyone can make an omelet with eggs. The trick is to make one with none.