OpenIndiana lead Alasdair Lumsden resigns
Posted Sep 5, 2012 23:57 UTC (Wed) by nix
In reply to: OpenIndiana lead Alasdair Lumsden resigns
Parent article: OpenIndiana lead Alasdair Lumsden resigns
Well, this is the kind of attention to detail that gives you (and Solaris, alas, if people should think you have anything to do with Solaris, which thankfully you do not) a bad name. (If people want to see what Solaris hackers are actually like, I recommend talking to Alan Coopersmith. A more charming and helpful man was never born.)
The -R (DT_RPATH) handling in Libtool was very carefully thought out specifically so as to work properly on both systems with an /etc/ld.so.conf-equivalent (like Linux) and systems which prefer DT_RPATH (like Solaris). If you have a problem with it, I might recommend you report it: but configure / make / make install with a variety of prefixes and DESTDIRs works perfectly in my testing. (There have been bugs in this area, but not for a long time). It is definitely unacceptable to just use DT_RPATH, since that would torpedo Linux systems. Instead, we provide an implementation which permits you to use -R to get the effect of DT_RPATH, while instead providing whatever implementation is preferred on the system being used (including 'none' for systems like Linux, if the user so requests). That's kind of what Libtool is all about, after all.
As for 'self modifying makefiles', you really do have no clue what you're talking about here. Autoconf is based on M4-driven generation of shell scripts. Automake is based on Perl-driven generation of makefiles (which do in fact warn about non-POSIX-make features, but most people sensibly don't care because GNU make is portable and most non-GNU makes are a horror show: here I explicitly include the coredumping halfwitted feature-free pile that is Solaris make: I have fairly frequent nightmares about the ten years I spent forced to keep things working with it).
Nothing whatsoever in GNU autotools is based on 'self-modifying Makefiles'. Perhaps you are talking about the dependency generation in Automake-driven makefiles, which does rely on generation of makefile fragments which are then included, but does not require self-modifying a makefile, unlike the 'make depend' system it generally replaced.
The makefile-fragment scheme may be 'a technique from the 1970s' but I'll note that this is both a non sequitur and untrue, since makes didn't have the ability to automatically reload their makefiles if their include dependencies had been modified until long long after that. Furthermore, it doesn't matter how old the scheme is: it works, and it is completely transparent to the user, unlike the horrible old 'make depend' system, which worked fine until you deleted or moved a file with generated dependencies, whereupon everything fell down in a screaming heap until you hand-hacked the dependencies or did a complete 'make clean' and rebuilt. Clearly you haven't read Paul D. Smith's excellent paper on this algorithm (due to Tom Tromey), which clearly describes the reasons why the scheme was implemented as it was.
(Actually, sorry, perhaps I was wrong: quite possibly you have read that paper. I'd forgotten how immune to reasoned argument you are. My apologies. For a moment I thought I was talking to a rational being.)
(corbet: sorry about the tone here, but I consider it important to refute schily's untruths, and further that, to be blunt, driving off schily before he converts the entire site into a single giant flamewar is more important than civility in this instance, not least since schily has long since proved himself incapable of civilized discourse. We are talking about someone who got himself banned from the Debian bugtracker(!) for repeated kibozing and trolling, after all.)
to post comments)