| |||||||||||||
LCA: Disintermediating distributionsLCA: Disintermediating distributionsPosted Feb 7, 2008 1:21 UTC (Thu) by stevenj (guest, #421)In reply to: LCA: Disintermediating distributions by stevenj Parent article: LCA: Disintermediating distributions By the way, don't get me wrong, the autotools are far from perfect. Life would be much much simpler for the autotools developers and users alike if they could rely on more than a small portable subset of sh and make being available on the build hosts. For one thing, it means that they have to use use three languages (sh, m4, and make) instead of one. For another thing, portable sh doesn't have functions so the generated configure scripts are huge and slow (launching lots of processes). For another thing, make is not integrated with the configure tests, so you can't parallelize the tests or run only those tests that are needed when something changes, and so on. The problem is that valid, constructive criticisms of the autotools largely get lost in the noise of people who argue from ignorance of the real complexity of the problems that these tools have to address, and which aren't addressed by most of the suggested alternatives.
(Log in to post comments)
LCA: Disintermediating distributions Posted Feb 7, 2008 7:57 UTC (Thu) by aleXXX (subscriber, #2742) [Link] > who argue from ignorance of the real complexity of the problems that > these tools have to address, and which aren't addressed by most of the > suggested alternatives. As maintainer of the KDE4 build system, which is able to build KDE4 on -Linux -FreeBSD -Solaris -Mac OSX (makefiles or XCode) -Windows (mingw + GNU make, cl + nmake or Visual Studio, not cygwin) I am well aware of the complexities and cmake handles them all. Alex
LCA: Disintermediating distributions Posted Feb 7, 2008 17:21 UTC (Thu) by stevenj (guest, #421) [Link] Libtool handles many, many more Unix flavors than that. Yes, if you are willing to restrict yourself to recent versions of five platforms, it simplifies life a lot.
LCA: Disintermediating distributions Posted Feb 7, 2008 19:09 UTC (Thu) by bronson (subscriber, #4806) [Link] In theory. In practice, I've spent many awful hours chasing libtool breakage on even the most common platforms. libtool adds extreme complexity to packages in an attempt to make them build everywhere. More software means more bugs. The end result is preductable: libtool packages often fail to build on even the most common platforms. First you need to track down and install the exact version of automake used by the packager, twiddle the configure file to remove syntax errors, try to figure out the magic combination of undocumented --enable and --disable switches that will actually compile, and so on... This whole process is more abstract and opaque than editing Makefiles directly, but is it better? Does it actually save time? libtool is a bad abstraction. Like CORBA, it tries to gloss over horrifyingly complex problems but, instead of solving them, it seems to just push them around. Perhaps I'm getting philisophical, but I think they too hard to insulate the user from the real world. D-Bus doesn't try as hard as CORBA and, as a result, it's much more usable and reliable. And a heck of a lot smaller. I feel like libtool could learn the same lesson. I worked as a release engineer, so I admittedly had to wrestle with libtool a lot more than the average person. The missing ' in configure was the winner; finding that that took 7 hours of binary searching an unreadable 350K shell script. For comparison, it takes 3-4 hours to learn how to use cmake from scratch! libtool solves some problems, creates others, and the end result seems to be a wash. Anyhow, that's just my experience. Not good. Allow me to cast my vote for a simpler libtool in the future.
LCA: Disintermediating distributions Posted Feb 7, 2008 22:52 UTC (Thu) by aleXXX (subscriber, #2742) [Link] The platforms I listed are the platforms where I know that KDE4 successfully builds. I don't know if anybody already tried to build KDE4 on NetBSD, AIX, QNX, HP-UX, IRIX, BeOS, DragonFly, Hurd or any of the other platforms CMake supports. I'm quite sure the bigger problems in getting KDE4 work there will be to get all the required libraries working on these platforms (dbus, some multimedia lib like xine, a compatible X, etc.) and to get the compiler actually compile the C++ code without errors (some compilers don't accept everything what gcc accepts, some because they are older, some because they are more picky). Alex
LCA: Disintermediating distributions Posted Feb 10, 2008 20:40 UTC (Sun) by oak (subscriber, #2786) [Link] My experience (mostly from about 10 years ago) has also been that Autotools (not just how they are used) are much larger problem for portability than the software they try to build. Autotools scripts work only on platforms that Autotools officially support. If you have just (GNU) make and shell like claimed above, Autotools falls down on its face, soils itself and cries for Mama. It was much easier just to build GNU make and re-write the build scripts as cleaner Makefiles instead of trying to port first the huge mass of Autotools dependencies (Perl being one of the first/larger roadblocks) and then debug what other software the scripts need (after a long build fails) + iterate that. For me the solution seems obvious. Solve the problem instead of kludging around it. It seems insane/impossible to try to make the scripts autotools generate to projects portable to "everything". Why not instead reduce Autotools script dependencies and make sure that those dependencies do everything needed and are portable to/buildable everywhere in addition to being standards compliant, small and of exemplary clean design? The very small downside would be that then those couple of binaries need to be built for given platform before the much cleaned up, debuggable, faster, saner and otherwise better new autotools scripts can be run. But as those programs are small & very portable, that should be trivial and including their binaries to CYGWIN and GNU coreutils would solve this for >90% of the developers. As a result, all world's embedded developers would thank you!
|
|||||||||||||