(unknown),

(unknown),

[John Darrington]

Thanks to Ludovic for showing me how to fix this.

[PATCH] gnu: Fix load-extension path in packaging of guile-ncurses.

[John Darrington]

* gnu/packages/guile.scm (guile-ncurses) [arguments]: Install shared object before
attempting to build the package.  Patch load-extension path before building instead
of after.
---
 gnu/packages/guile.scm | 22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index 1653685..741728d 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -431,16 +431,20 @@ many readers as needed).")
                                "--with-gnu-filesystem-hierarchy")
        #:phases
        (modify-phases %standard-phases
-         (add-after 'install 'post-install
+         (add-before 'build 'fix-libguile-ncurses-file-name
            (lambda* (#:key outputs #:allow-other-keys)
-             (let* ((out   (assoc-ref outputs "out"))
-                    (dir   (string-append out "/share/guile/site/"))
-                    (files (find-files dir ".scm")))
-               (substitute* files
-                 (("\"libguile-ncurses\"")
-                  (format #f "\"~a/lib/guile/2.0/libguile-ncurses\""
-                          out)))
-               #t))))))
+             (and (zero? (system* "make" "install"
+                                  "-C" "src/ncurses"
+                                  "-j" (number->string
+                                        (parallel-job-count))))
+                  (let* ((out   (assoc-ref outputs "out"))
+                         (dir   "src/ncurses")
+                         (files (find-files dir ".scm")))
+                    (substitute* files
+                      (("\"libguile-ncurses\"")
+                       (format #f "\"~a/lib/guile/2.0/libguile-ncurses\""
+                               out)))
+                    #t)))))))
     (home-page "https://www.gnu.org/software/guile-ncurses/")
     (synopsis "Guile bindings to ncurses")
     (description
-- 
2.1.4

Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses.

[Ludovic Courtès]

John Darrington <jmd@gnu.org> skribis:

> * gnu/packages/guile.scm (guile-ncurses) [arguments]: Install shared object before
> attempting to build the package.  Patch load-extension path before building instead
> of after.

OK, thank you!

Ludo’.

Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses.

[Mark H Weaver]

Hi John,

John Darrington <jmd@gnu.org> writes:
> * gnu/packages/guile.scm (guile-ncurses) [arguments]: Install shared object before
> attempting to build the package.  Patch load-extension path before building instead
> of after.

The first sentence above is mistaken or misleading:

  "Install shared object before attempting to build the package."

Of course this is not possible, and it's not what happens after applying
this commit.

> +         (add-before 'build 'fix-libguile-ncurses-file-name
>             (lambda* (#:key outputs #:allow-other-keys)
> - [...]
> +             (and (zero? (system* "make" "install"
> +                                  "-C" "src/ncurses"
> +                                  "-j" (number->string
> +                                        (parallel-job-count))))
> +                  (let* ((out   (assoc-ref outputs "out"))
> +                         (dir   "src/ncurses")
> +                         (files (find-files dir ".scm")))
> +                    (substitute* files
> +                      (("\"libguile-ncurses\"")
> +                       (format #f "\"~a/lib/guile/2.0/libguile-ncurses\""
> +                               out)))
> +                    #t)))))))

By running "make install -C src/ncurses [...]", you are in fact causing
most if not all of the package to be built and installed right here in
the 'fix-libguile-ncurses-file-name' phase.  This is no good.

Can you help me understand what you're trying to do here, and why?

     Thanks,
       Mark

Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses.

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 2965 bytes --]

On Tue, Dec 20, 2016 at 02:17:42AM -0500, Mark H Weaver wrote:
     Hi John,
     
     John Darrington <jmd@gnu.org> writes:
     > * gnu/packages/guile.scm (guile-ncurses) [arguments]: Install shared object before
     > attempting to build the package.  Patch load-extension path before building instead
     > of after.
     
     The first sentence above is mistaken or misleading:
     
       "Install shared object before attempting to build the package."

How about I change it to "... attempting to build the rest of the package" ??

     > +         (add-before 'build 'fix-libguile-ncurses-file-name
     >             (lambda* (#:key outputs #:allow-other-keys)
     > - [...]
     > +             (and (zero? (system* "make" "install"
     > +                                  "-C" "src/ncurses"
     > +                                  "-j" (number->string
     > +                                        (parallel-job-count))))
     > +                  (let* ((out   (assoc-ref outputs "out"))
     > +                         (dir   "src/ncurses")
     > +                         (files (find-files dir ".scm")))
     > +                    (substitute* files
     > +                      (("\"libguile-ncurses\"")
     > +                       (format #f "\"~a/lib/guile/2.0/libguile-ncurses\""
     > +                               out)))
     > +                    #t)))))))
     
     By running "make install -C src/ncurses [...]", you are in fact causing
     most if not all of the package to be built and installed right here in
     the 'fix-libguile-ncurses-file-name' phase.

I didn't check to see what percentage of the package is contained in the 
src/ncurses directory, but it certainly isn't "all".

     This is no good.

Why do you think it is "no good"?  It may not be perfect, but it is better
than what we had before, and certainly fixes the problem.

     
     Can you help me understand what you're trying to do here, and why?
     
Sure (I would like to see a convention where such explanations are
put in the commit messaage, but I have previously been outvoted on
that issue):

The scheme code contains a number of procedures similar to 
(load-extension "libguile-ncurses" "func"). We need the first
string to contain the absolute path where the shared object is 
installed.   The previous version had done this by patching the 
.scm file post-installation.  However that meant that the compiled
.go file was compiled with the old, unmodified version.  
This patch ensures that the .scm files are patched first, and that
the .go files are built from the patched .scm files.

I hope this makes things clearer for you.

J'


-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses.

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

On Tue, Dec 20, 2016 at 12:03:31PM +0100, John Darrington wrote:
     On Tue, Dec 20, 2016 at 02:17:42AM -0500, Mark H Weaver wrote:

     The scheme code contains a number of procedures similar to 
     (load-extension "libguile-ncurses" "func"). We need the first
     string to contain the absolute path where the shared object is 
     installed.   The previous version had done this by patching the 

      ^^^ 
For clarification, when I say "installed" here,  I mean it's location 
in /gnu/store.

     .scm file post-installation.  However that meant that the compiled
     .go file was compiled with the old, unmodified version.  
     This patch ensures that the .scm files are patched first, and that
     the .go files are built from the patched .scm files.
     



-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses.

[Danny Milosavljevic]

> Sure (I would like to see a convention where such explanations are
> put in the commit messaage, but I have previously been outvoted on
> that issue):

No, please don't put explanations into the commit message. But do put them into the source code as a comment.

I'm also working on other projects, some of which do what you propose. What I often end up having to do there is do git blame, then git log for each line, in order to find out why the source code does what it does. Let's not do that here. There's a perfectly good inline mechanism for it: Comments.

Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses.

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 3710 bytes --]

On Wed, Dec 21, 2016 at 09:36:56AM +0100, Danny Milosavljevic wrote:
     > Sure (I would like to see a convention where such explanations are
     > put in the commit messaage, but I have previously been outvoted on
     > that issue):

Hi Danny, 

A small request: Can you please fold the text of your email to ~80 
characters.  It's very hard to read otherwise.
     
     No, please don't put explanations into the commit message. But do put them into the source code as a comment.

That approach can work sometimes, but more often it is a non-starter.

A few example scenarios:

1. Suppose I need to do a global search and replace, changing a variable name 
across many files.  It would be ludicrous  to have in dozens of files:

;; This variable used to be called "bar" but we changed it to "foo" because ...
(+ foo 4)

When reviewing the code, frankly nobody CARES what it used to be called!


2. Suppose we decide to delete something from a file. It would be equally 
ludicrous to have:

;; There used to be some code here which did:
;;(large-block-of-code
;;.
;;.
;;.
;;.
;;.
;;.)
;; but we decided to delete it because ...

Again I don't care what used to be in a file.


3.  Suppose that, due to a design change, a new variable has to be 
introduced in places thoughout the code:  It would be bizarre, 
distracting and stupid to have in many places:

;; Since we introduced the frobnicator module the signature for
;; calling wiz needs to pass it as an argument.
(wiz frobnicator)



4. Suppose I fix a bug:  It would be pejorative to write:

;; Fred Bloggs who wrote the function typed 'xyz' when he
;; ought to have put 'abc', because ...


I am just glad when a bug has been fixed.  If somebody changes
some code of mine, I might be curious as to why.  In that case
I can check the git log.  If that person has (like he should)
explained in the git log why my code was wrong, I will be 
gratefull for the explanation and the fix.  But nobody except
me will care about bugs in the function which have been fixed.


     I'm also working on other projects, some of which do what you propose. What I often end up having to do there is do git blame, then git log for each line, in order to find out why the source code does what it does. Let's not do that here. 

That is what git blame is for.  Be thankful for it!

  There's a perfectly good inline mechanism for it: Comments.

I am not saying that no explanations of *current* code should 
be put in comments.  It is of course good practice to explain
the working of tricky parts of code.  But to put a *history*
of the code inline is just distraction and a misuse of comments.


Your proposal takes us back to the 1970s - Occassionally I come across
code done like that.  It is  a nightmare to follow.  I am not normally
interested in the history of the code when I look a the source.  I am 
interested in what it does now.   If I want the history, then use git.
That is (amoung other things) what it was designed for.


I hope this explains why putting history in comments is harmful.
Having it in the commit message would certainly have avoided me
having to explain the situation to Mark too.


If this doesn't convince you, then I don't know what more I can say.
But I find that our current git logs are just useless.  They don't
tell me anything which I couldn't have found out by running 
git diff/git blame.

J'


-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses.

[Tobias Geerinckx-Rice]

[-- Attachment #1.1: Type: text/plain, Size: 3998 bytes --]

John, Danny,

[Any exasperation is due only to the sustained level of FUD I encounter
about the Guix/GNU changelog format, and not aimed at John.]

On 20/12/16 12:03, John Darrington wrote:
> Sure (I would like to see a convention where such explanations are 
> put in the commit messaage, but I have previously been outvoted on 
> that issue).

I don't think so.

1. What was ‘outvoted’ (with solid argumentation) was hiding comments
documenting code itself in commit messages, when they would do more
good as, well, comments.

2. The Guix commit log has plenty of concise explanations for why code
was *changed*. I See 64b5e41 for a random example. If that guy can get
away with it...

Most People™ badly overdo #2 when they should do #1 (consider the
average *Hub pull request). The opposite is less common.

> On Wed, Dec 21, 2016 at 09:36:56AM +0100, Danny Milosavljevic wrote:
>> No, please don't put explanations into the commit message. But do 
>> put them into the source code as a comment.

I'd just finished writing the exact same e-mail as Danny — almost to the
sentence — when that arrived. So... it must be right! :-)

> That approach can work sometimes, but more often it is a 
> non-starter.

[Examples paraphrased for length:]
> 1. ;; This variable used to be called "bar" but we changed it
> 2. ;; There used to be some code here but we deleted it
> 3. A new variable was introduced in places thoughout the code
> 4. ;; Fred typed 'xyz' when he ought to have put 'abc'

Sorry, but the first three examples are silly. :-)

Deliberately silly, I'm sure, but still these are strawmen that no-one
proposed. On the contrary: examples 1 to 3 are exactly what the current
commit log documents with tedious precision.

That leaves bugfixes.

If the bug is waiting to happen again (and again...), putting a warning
to future readers in a comment might be appropriate. No-one will spot it
in a commit message. (Of course, re-writing the misleading/dangerous
code would be the best solution.)

If the fix is trivial, as in this example, the diff usually speaks for
itself. In all other cases, a short note in the commit message is fine.
This seems to be standard policy for CVEs. So I really don't understand
your complaint.

> But nobody except me will care about bugs in the function which have
> been fixed.

Exactly! In this patch, you're replacing buggy (?) code with shiny code.
That shouldn't take more than ~50 characters to note.

> On Wed, Dec 21, 2016 at 09:36:56AM +0100, Danny Milosavljevic wrote:
>> I'm also working on other projects, some of which do what you 
>> propose. What I often end up having to do there is do git blame, 
>> then git log for each line, in order to find out why the source 
>> code does what it does. Let's not do that here.

+11, unfortunately from experience.

> That is what git blame is for.  Be thankful for it!

No and God no.

That is exactly what ‘git blame’ is not for.

Code itself should be documented in-line. Not in a commit log meant for
documenting changes, that breaks as soon as someone hits C-M-q.

> I hope this explains why putting history in comments is harmful.

It does! But this is not something anyone here suggested.

> Having it in the commit message would certainly have avoided me 
> having to explain the situation to Mark too.

Perhaps. I doubt it. I can't speak for Mark, but most confusion
seemed to stem from the commit message's accuracy, not its length.

But yes, it could have been longer — and a comment :-)

Kind regards,

T G-R

PS: On 21/12/16 10:56, John Darrington wrote:
> Hi Danny,
> 
> A small request: Can you please fold the text of your email to ~80 
> characters.  It's very hard to read otherwise.

FWIW, your replies are equally hard to read (and even harder to reply
to) because of the unconventional indentation. It certainly confuses
Thunderbird, which is easily confused.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 476 bytes --]

Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses.

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 5104 bytes --]

We can argue about this till we're blue in the face.

But on a pragmatic level, Mark's question demonstrates perfectly
that our current system is lacking.  Other projects I work on
which have a more conventional approach do not suffer from this problem.

J'

On Thu, Dec 22, 2016 at 06:56:56AM +0100, Tobias Geerinckx-Rice wrote:
     John, Danny,
     
     [Any exasperation is due only to the sustained level of FUD I encounter
     about the Guix/GNU changelog format, and not aimed at John.]
     
     On 20/12/16 12:03, John Darrington wrote:
     > Sure (I would like to see a convention where such explanations are 
     > put in the commit messaage, but I have previously been outvoted on 
     > that issue).
     
     I don't think so.
     
     1. What was ???outvoted??? (with solid argumentation) was hiding comments
     documenting code itself in commit messages, when they would do more
     good as, well, comments.
     
     2. The Guix commit log has plenty of concise explanations for why code
     was *changed*. I See 64b5e41 for a random example. If that guy can get
     away with it...
     
     Most People??? badly overdo #2 when they should do #1 (consider the
     average *Hub pull request). The opposite is less common.
     
     > On Wed, Dec 21, 2016 at 09:36:56AM +0100, Danny Milosavljevic wrote:
     >> No, please don't put explanations into the commit message. But do 
     >> put them into the source code as a comment.
     
     I'd just finished writing the exact same e-mail as Danny ??? almost to the
     sentence ??? when that arrived. So... it must be right! :-)
     
     > That approach can work sometimes, but more often it is a 
     > non-starter.
     
     [Examples paraphrased for length:]
     > 1. ;; This variable used to be called "bar" but we changed it
     > 2. ;; There used to be some code here but we deleted it
     > 3. A new variable was introduced in places thoughout the code
     > 4. ;; Fred typed 'xyz' when he ought to have put 'abc'
     
     Sorry, but the first three examples are silly. :-)
     
     Deliberately silly, I'm sure, but still these are strawmen that no-one
     proposed. On the contrary: examples 1 to 3 are exactly what the current
     commit log documents with tedious precision.
     
     That leaves bugfixes.
     
     If the bug is waiting to happen again (and again...), putting a warning
     to future readers in a comment might be appropriate. No-one will spot it
     in a commit message. (Of course, re-writing the misleading/dangerous
     code would be the best solution.)
     
     If the fix is trivial, as in this example, the diff usually speaks for
     itself. In all other cases, a short note in the commit message is fine.
     This seems to be standard policy for CVEs. So I really don't understand
     your complaint.
     
     > But nobody except me will care about bugs in the function which have
     > been fixed.
     
     Exactly! In this patch, you're replacing buggy (?) code with shiny code.
     That shouldn't take more than ~50 characters to note.
     
     > On Wed, Dec 21, 2016 at 09:36:56AM +0100, Danny Milosavljevic wrote:
     >> I'm also working on other projects, some of which do what you 
     >> propose. What I often end up having to do there is do git blame, 
     >> then git log for each line, in order to find out why the source 
     >> code does what it does. Let's not do that here.
     
     +11, unfortunately from experience.
     
     > That is what git blame is for.  Be thankful for it!
     
     No and God no.
     
     That is exactly what ???git blame??? is not for.
     
     Code itself should be documented in-line. Not in a commit log meant for
     documenting changes, that breaks as soon as someone hits C-M-q.
     
     > I hope this explains why putting history in comments is harmful.
     
     It does! But this is not something anyone here suggested.
     
     > Having it in the commit message would certainly have avoided me 
     > having to explain the situation to Mark too.
     
     Perhaps. I doubt it. I can't speak for Mark, but most confusion
     seemed to stem from the commit message's accuracy, not its length.
     
     But yes, it could have been longer ??? and a comment :-)
     
     Kind regards,
     
     T G-R
     
     PS: On 21/12/16 10:56, John Darrington wrote:
     > Hi Danny,
     > 
     > A small request: Can you please fold the text of your email to ~80 
     > characters.  It's very hard to read otherwise.
     
     FWIW, your replies are equally hard to read (and even harder to reply
     to) because of the unconventional indentation. It certainly confuses
     Thunderbird, which is easily confused.
     




-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses.

[Mark H Weaver]

John Darrington <john@darrington.wattle.id.au> writes:

> We can argue about this till we're blue in the face.
>
> But on a pragmatic level, Mark's question demonstrates perfectly
> that our current system is lacking.

No it doesn't.  Our convention, taken from the GNU coding standards, is
that the rationale for non-obvious code belongs in the code itself.  My
question demonstrates perfectly that you should have done _that_.

For what it's worth, I agree that there are some cases where adding
rationale comments to the code itself doesn't make sense (e.g. when
removing code), but this is clearly not one of those cases.

>      > Having it in the commit message would certainly have avoided me 
>      > having to explain the situation to Mark too.
>      
>      Perhaps. I doubt it. I can't speak for Mark, but most confusion
>      seemed to stem from the commit message's accuracy, not its length.

Yes, exactly.

To be honest, I find it unsettling that after all that has been pointed
out in this thread, you still seem unwilling to admit that you made any
mistake here.

Have you looked at the build log, and specifically the part of the build
log that corresponds to your 'fix-libguile-ncurses-file-name' phase?

Have you noticed how the 'build' and 'install' phases consist mostly of
commands that were already run in your custom phase?

Do you still think that "Install shared object before attempting to
build the package" is an accurate statement?

       Mark

Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses.

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]

On Sat, Dec 24, 2016 at 10:39:40AM -0500, Mark H Weaver wrote:
     John Darrington <john@darrington.wattle.id.au> writes:
     
     > We can argue about this till we're blue in the face.
     >
     > But on a pragmatic level, Mark's question demonstrates perfectly
     > that our current system is lacking.
     
     No it doesn't.  Our convention, taken from the GNU coding standards, is
     that the rationale for non-obvious code belongs in the code itself.  My
     question demonstrates perfectly that you should have done _that_.
     
     For what it's worth, I agree that there are some cases where adding
     rationale comments to the code itself doesn't make sense (e.g. when
     removing code), but this is clearly not one of those cases.
     
     >      > Having it in the commit message would certainly have avoided me 
     >      > having to explain the situation to Mark too.
     >      
     >      Perhaps. I doubt it. I can't speak for Mark, but most confusion
     >      seemed to stem from the commit message's accuracy, not its length.
     
     Yes, exactly.
     
     To be honest, I find it unsettling that after all that has been pointed
     out in this thread, you still seem unwilling to admit that you made any
     mistake here.
     
     Have you looked at the build log, and specifically the part of the build
     log that corresponds to your 'fix-libguile-ncurses-file-name' phase?
     
     Have you noticed how the 'build' and 'install' phases consist mostly of
     commands that were already run in your custom phase?
     
     Do you still think that "Install shared object before attempting to
     build the package" is an accurate statement?
     
I offered to change this comment.  You have ignored my offer.  Why are you 
determined to start an argument?


-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH] gnu: Fix load-extension path in packaging of guile-ncurses.

[Mark H Weaver]

John Darrington <john@darrington.wattle.id.au> writes:

> On Sat, Dec 24, 2016 at 10:39:40AM -0500, Mark H Weaver wrote:
>      John Darrington <john@darrington.wattle.id.au> writes:
>      
>      > We can argue about this till we're blue in the face.
>      >
>      > But on a pragmatic level, Mark's question demonstrates perfectly
>      > that our current system is lacking.
>      
>      No it doesn't.  Our convention, taken from the GNU coding standards, is
>      that the rationale for non-obvious code belongs in the code itself.  My
>      question demonstrates perfectly that you should have done _that_.
>      
>      For what it's worth, I agree that there are some cases where adding
>      rationale comments to the code itself doesn't make sense (e.g. when
>      removing code), but this is clearly not one of those cases.
>      
>      >      > Having it in the commit message would certainly have avoided me 
>      >      > having to explain the situation to Mark too.
>      >      
>      >      Perhaps. I doubt it. I can't speak for Mark, but most confusion
>      >      seemed to stem from the commit message's accuracy, not its length.
>      
>      Yes, exactly.
>      
>      To be honest, I find it unsettling that after all that has been pointed
>      out in this thread, you still seem unwilling to admit that you made any
>      mistake here.
>      
>      Have you looked at the build log, and specifically the part of the build
>      log that corresponds to your 'fix-libguile-ncurses-file-name' phase?
>      
>      Have you noticed how the 'build' and 'install' phases consist mostly of
>      commands that were already run in your custom phase?
>      
>      Do you still think that "Install shared object before attempting to
>      build the package" is an accurate statement?
>      
> I offered to change this comment.  You have ignored my offer.

It's impossible to change that comment, because it's in the commit log.
That's yet another reason why the source code itself is a better place
for documentation than the commit logs.

      Mark