Michael T. Richter wrote:
On Fri, 2007-27-04 at 13:09 +0100, Robin Green wrote:
> But just think about it... is it easier to DOCUMENT the problem or
> just include a workaround in the make install code?
It's easier to document the problem.
For the individual developer it is easier to document the problem. For
the development community as a whole it is easier if individual
developers fix problems or at least make them more easily spotted than
obscure notes in gigantic README files.
For the individual developer it takes, hypothetically, two minutes to
add a note to the effect that an out-of-date version of libreadline is
required while it may take ten minutes to add a check to the configure
script (and test it!) and even a day to fix the problem to work with the
current version of libreadline. So yes, it is easier to document. By far.
But now broaden the scope to the community. The compiler is
downloaded. The process of building it begins. (It does take a long
time to build GHC...) The user waits that long time and ... the build
fails. Now s/he has to search through output whose error messages are
not exactly the most friendly in the world. Typically, for example,
you're about five levels deep into make and the error message that
actually tells you what's wrong is in backscroll. So you find that
message and slap your forehead. Doh! You download and install your old
version of libreadline and try again. Time wasted? Ten minutes at
least. More likely half an hour. Lather. Rinse. Repeat. (There are
probably other dependencies to outdated packages, after all.)
OK, let's go the RTFM route. Each and every developer reads each and
every README file in each and every project combing it for references to
bizarre dependencies. Let's be hyper-generous and say that each
developer only spends one minute on the README file; that the README
files in question are a paragon of informational organisation (instead
of the more usual data dump in no particular order). Let's further
suggest that it takes only five minutes to get all the unexpected
dependencies worked out, downloaded and compiled/installed. Total time
to make up the fix? Six minutes.
That one minute to find the information in the README file is far
shorter than the time it would take to add the equivalent logic to the
configure script. So if you have one to nine end-users, the net time
wasted to document instead of modifying the configure script is less.
But I think that GHC has quite a few more than nine end-users. The
aggregate time wasted in the community (without even factoring in the
time required to compile/install the desired version of libreadline)
suddenly becomes much higher than the time saved by not writing that
configure script modification. Indeed I suspect that the aggregate time
wasted would be sufficient to justify the modification of the code to
support the latest version of libreadline in the first place once you
factor in the time wasted compiling/installing the correct libreadline
version.
Now what relevance does any of this have to the individual developer?
Why would s/he care about the end-user experience? Well, let us not
forget that said individual developer is part of that overall
community. That said individual developer faces exactly the same wastes
of time poring over README files (or, more likely, bizarre build errors)
to figure out how to get the tools they use to compile. That said
developer, too, would be more productive individually, not to mention
the community as a whole, if the majority of the development community's
members were to fix problems rather than documenting them.
All these would be a very good points except they do not match the actual
situation at all.
1) The compiler was not built from source.
2) The compiler built successfully.
3)
[EMAIL PROTECTED] ghc-6.6.1]# ghc
/usr/local/lib/ghc-6.6.1/ghc-6.6.1: error while loading shared libraries:
libreadline.so.4: cannot open shared object file: No such file or directory
Finding one line in one line of output... quite a bit of rooting around.
4) The fix to the "bug" is simply download and install the libreadline4 shared
object. No recompilation or reinstallation necessary.
5) The "gigantic README" with it's "obscure note" is here
http://www.haskell.org/ghc/download_ghc_661.html a few lines away from the
download link. You can probably read it in the time it takes you to find and
click the download link. Much quicker than waiting for a configure script to
detect the problem.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe