References: 1. http://de.wikipedia.org/wiki/Autoconf german, but the english version doesnt include critcs; maybe some native english speaker can add some?) In short: There's a section called critics, stating auto* works well on Linux/GNU (add from me: or, with some luck, any modern UNIX as long you use gcc + a bunch of GNU tools you otherwise probably dont need), but often fails on other systems. It has several weaknesses. (I didnt write that article) 2. http://lwn.net/Articles/188693/ "Why the KDE project switched to CMake -- and how"
We need autotools for the deps and KBE, right? I dont like tools that compile software with limited features because some automagic decides (wrong) my system is like 2005, although I have a current version as of 09/2007. I dont like software with a built-in substitute for a system library function that already _is_ in my system libs. Quick hacks, naturally mostly untested. I have no confidence in tools that claim to provide ease and built-in expertise, and when I use them they start a compile run with Studio cc and options for GCC or the other way around. Using autoconf is extremely dangerous. It's M$ (or some other's) merchandising tactics aplied to software development: "Here you have a wonderful tool, it will take all the burden from you! Just give me your Makefile. You dont need that anymore." and once you're a customer, you can't use another built tool chain other than GCC + autotools + all they depend on. I like the FSF, what Stallman started and others put forth was revolutionary and I think he's earned the Nobel Peace Price. But... I wonder how difficult it would be to get rid of it. Would this step lower the number of deps? I.e. are there dependants that are only in because the auto tool chain pulls them in? You did the right thing what seemed to be a no-go: replace gcc by Studio + Apache stdcxx lib. "SPECmeister" wrote a SPEC conversion, where others would potentially write all specs manually. I mean I feel here are people who dont just blindly take a bunch of software + gcc, tweak the configuration settings until it compiles and then shout "done!". Would this be practical? Would it potentially reduce maintenance effort in the long term? Am I wrong, and the auto* problem is not that urgent, we can handle it, and all I need is some more insight and training in how this toolchain works? E.g. it can cache results, we dont use that currently. Do I shoot myself in the foot when I enable that? Last topic: KDE3. KDE4 is in it's final development stage, so from my experience I dont expect a usable KDE4 desktop on OS before summer; even that is optimistic. And the stable KDE3 uses auto*, I already expressed my aversion. But I want a usable KDE. GCC compiled thing from blastwave breakes my system, it's for 5.8,9,10. Someone has pkgs for 5.11, but it's GCC + auto*, no thanks. It can not be interoperable with the rest of the underlying OS, otherwise most of all I know about IT is wrong. The question is: Do I have a chance to take the Apache stdcxx lib you ported and with some persistence get KDE3(.5[78]) up from source? Thanks in advance, Paul -- This message posted from opensolaris.org
