| |||||||||||||
automake vs. GNU makeautomake vs. GNU makePosted Feb 7, 2008 16:59 UTC (Thu) by vmole (guest, #111)In reply to: automake vs. GNU make by stevenj Parent article: LCA: Disintermediating distributions
No, my point is that problem is so complex that pretending you can hide it with libtool is misleading. The developers have know and care that AIX and MinGW are different, and need special variations, or the end-user, trying to build the package, has to track down the docs and figure out where to add the magic option. You're right: I'm pretty ignorant about the internal details of autoconf et. al. But as an end user, who has 20+ years of experience building software on a wide variety of platforms, I've found that I spent a lot more time fighting autoconf/automake/libtool problems than I did for packages that asked me to uncomment the appropriate variable settings in the Makefile. Why? Because if the appropriate variable was available in the Makefile, then someone had actually, really, already built it on that platform. If not, then it was pretty easy to see what needed to be done. I should clarify: by "autoconf problems" I don't necessarily mean problems with the autoconf system itself. It does what it's told. The problem is software developers who believe that using autoconf et. al. magically solves all their portability issues, and all they need to do is copy a few scripts/templates from some other project. This is the "autoconf culture" problem I mentioned way back in my first comment. It may not be what the autoconf developers intended or wanted, but it sure is what has happened. That's all for me.
(Log in to post comments)
automake vs. GNU make Posted Feb 7, 2008 21:36 UTC (Thu) by nix (subscriber, #2304) [Link] No, my point is that problem is so complex that pretending you can hide it with libtool is misleading. The developers have know and care that AIX and MinGW are different, and need special variations, or the end-user, trying to build the package, has to track down the docs and figure out where to add the magic option.Actually, if you use libtool and libltdl you *don't* need to care that Linux, Solaris, MacOS X, AIX, HP-UX 10 and Windows all use quite different methods to build shared libraries with different names and semantics; at least not unless you're trying to go beyond what static libraries allow and do symbol versioning or something like that. The end-user need have no clue at all. libtool has its problems (astonishing sloth being one of them: why anyone complains that configure takes too long to run for very small projects, when libtool slows down building drastically regardless of project size, I have no idea) but you don't seem to know what those problems are. At least you're focusing on men made of straw when there are perfectly visible giants of problems looming a few feet away.
automake vs. GNU make Posted Feb 7, 2008 21:55 UTC (Thu) by vmole (guest, #111) [Link] Actually, if you use libtool and libltdl you *don't* need to care that Linux, Solaris, MacOS X, AIX, HP-UX 10 and Windows all use quite different methods to build shared libraries with different names and semantics ... The end-user need have no clue at all. Yes, that's the promise. But in my experience (and in many others), as the end user of several libtool using projects, it's not reality. Is it that all these projects are setting things up wrong? Possibly. I don't know, and I don't really care, because if so, it's apparently as hard to get right as using the actual OS tools would be, which would at least be debuggable by normal human beings. And I'm well aware and have suffered extensively at libtool's sloth. And its insanely long invocation lines, which make make logs painful to read and hide errors.
automake vs. GNU make Posted Feb 7, 2008 23:18 UTC (Thu) by nix (subscriber, #2304) [Link] Your reality differs from my reality. I've had some cosmetic problems on Solaris 2.4 and 2.5.1 (we're talking prehistoric here) and I needed to install GNU sed on HP-UX and AIX, but other than that, nothing really. (Mind you, the need for GNU sed *was* unacceptable --- it was also a bug.)
automake vs. GNU make Posted Feb 7, 2008 23:25 UTC (Thu) by aleXXX (subscriber, #2742) [Link] > [libtool is] apparently as hard to get right as using the actual OS > tools would be, which would at least be debuggable by normal human > beings. "at least be debuggable" - very well put, I completely agree. Why does automake actually need libtool at all ? I mean it generates the makefile code, it could as well just generate the code for calling the actual OS tools directly in the makefiles. This would remove this one layer of indirection. Alex
automake vs. GNU make Posted Feb 8, 2008 0:44 UTC (Fri) by nix (subscriber, #2304) [Link] automake can't generate the commands libtool executes because automake runs on the distributor's machine, not the builder's, and doesn't have a clue what sort of system the build will take place on.
automake vs. GNU make Posted Feb 8, 2008 7:20 UTC (Fri) by aleXXX (subscriber, #2742) [Link] Ah, yes, indeed. (I didn't work with autotools in the last years). Then, couldn't the configure script handle that ? It runs on the build machine. Alex
automake vs. GNU make Posted Feb 8, 2008 21:28 UTC (Fri) by nix (subscriber, #2304) [Link] Yes, it could: but in libtool 1.5 it doesn't :( I never said libtool didn't suck. It's just better than anything else around right now for the job it does, and it has a *lot* of hard-won knowledge of shared library wierdness on manifold systems encoded into it (as autoconf does of other cross-system variation).
automake vs. GNU make Posted Feb 7, 2008 23:54 UTC (Thu) by stevenj (guest, #421) [Link] You didn't read the manual, and as a result it failed on AIX because you asked libtool to support semantics unavailable on that platform, and as a result you loudly complain here that libtool is broken and buggy. This is not a convincing critique of libtool.libtool solves a big part of the problem: its manual specifies the lowest common denominator of shared library semantics, tells you how to indicate whether you obey those semantics, and builds the resulting library on every system that supports the semantics you request. The fact that you still have to know that there might be some differences between systems, and that you might have to read the manual to learn how to deal with these differences, is not a reason to throw it out and rewrite everything yourself from scratch (the only other "solution" you have suggested). No matter what portability tool you use, developers will still need to know something about the differences between platforms.
automake vs. GNU make Posted Feb 8, 2008 0:23 UTC (Fri) by vmole (guest, #111) [Link] You didn't read the manual, and as a result it failed on AIX because you asked libtool to support semantics unavailable on that platform *I* didn't ask libtool to do anything. I'm the end-user. I'm not supposed to have know about libtool, or the variations in shared library implementations. Right? Isn't that the whole friggin point? And if your response is "But there's too many differences, libtool can't hide everything", then we are in 100% agreement. Where we differ is whether or not it's worth the attempt, and whether libtool is the correct direction. So be it. But if you continue to ignore those of us who have problems, and blame the users, well, it will never get better.
automake vs. GNU make Posted Feb 8, 2008 0:42 UTC (Fri) by stevenj (guest, #421) [Link] You haven't suggested any way for things to get better, you've just flamed a tool because you've encountered a couple of buggy packages that misused it, and it didn't correct for all the deficiencies of the developers. Then you tried to debug the problem yourself and failed because you didn't bother to read the fine manual.Your suggestions, as far as I can tell, have been either for every developer to reinvent the wheel by rolling their own platform-dependent scripts, or for the developers to push the whole problem onto the end-users by giving them a raw Makefile and telling them to fix the compiler options themselves. Neither of these seems like an improvement.
|
|||||||||||||