First, let's look at the current code in question: https://github.com/vim/vim/blob/master/src/configure.ac#L1878-L1889
1 if test -f "$rubylibdir/$librubya"; then 2 librubyarg="$librubyarg" 3 RUBY_LIBS="$RUBY_LIBS -L$rubylibdir" 4 elif test "$librubyarg" = "libruby.a"; then 5 dnl required on Mac OS 10.3 where libruby.a doesn't exist 6 librubyarg="-lruby" 7 RUBY_LIBS="$RUBY_LIBS -L$rubylibdir" 8 fi 9 10 if test "X$librubyarg" != "X"; then 11 RUBY_LIBS="$librubyarg $RUBY_LIBS" 12 fi After all, in order to have our build system find the Ruby library of non-standard installation and use the search result for Vim to link against it, all we need to do is to always include -L$rubylibdir in RUBY_LIBS. We have had the two patches to attain that so far, yours and mine. After applyting yours to configure.ac, we have 1 if test -f "$rubylibdir/$librubya"; then 2 librubyarg="$librubyarg" 3 RUBY_LIBS="$RUBY_LIBS -L$rubylibdir" 4 elif test "X`echo \"$librubya\" | $GREP -e \"libruby.*\\.a\"`" != "X"; then 5 dnl required on Mac OS 10.3 where libruby.a doesn't exist 6 librubyarg="-lruby" 7 RUBY_LIBS="$RUBY_LIBS -L$rubylibdir" 8 fi 9 10 if test "X$librubyarg" != "X"; then 11 RUBY_LIBS="$librubyarg $RUBY_LIBS" 12 fi As for my patch: 1 if test "$librubyarg" = "libruby.a" -a ! -f "$rubylibdir/$librubya"; then 2 dnl Workaround for the case where $librubyarg is set to non-existent 3 dnl libruby.a. Use the shared library instead. This happens with Mac 4 dnl OS X 10.3. 5 librubyarg="-lruby" 6 fi 7 RUBY_LIBS="-L$rubylibdir $librubyarg $RUBY_LIBS" Yours is made on top of the current fix for Mac OS X 10.3 which you described as "I had my reservations about the whole librubyarg/librubya thing, which seemed wrong and confusing to me (and still does seem wrong)." Are you saying you made your patch on top of the code which you think is wrong? How do you verify the correctness of yours yourself? Furthermore, if yours is included, the role of the elif block doubles: one for fixing the 10.3 bug; another for always including the correct -L option. They are completely different issues in themselves. What's the point to make the code more convoluted, which things have already been beyond your understanding? That will make not only you yourself but also people confuse more. On the other hand, mine goes straight to RUBY_LIBS="-L$rubylibdir $librubyarg $RUBY_LIBS" which is supporsed to work for every platform/installation unless RbConfig returns incorrect values, that is, except for the case of Mac OS X 10.3. It's clear, simple and short (If that verbose comment is deleted, the SLOC reduces to one-third of the original). What's wrong with it? What do you think I'm missing? 2017-11-26 19:40 GMT+09:00 Ilya Mikhaltsou <[email protected]>: > > See: https://github.com/vim/vim/blob/master/src/configure.ac#L1878-L1879 > . What I quoted is part of src/configure.ac in our official repository. > > > > > > And, the first two lines of those snippets of code are identical with > each other except for, in the latter snippet, the comments given by > someone. > > > > I don't understand what you are implying here. > > > That's exactly what the code tells me. I've already known about that. > > Wasn't clear for me from your comments, sorry. > > > That will never happen: After applying my patch, the relevant part of > configure.ac becomes > > > > > > > > if test "$librubyarg" = "libruby.a" -a ! -f > "$rubylibdir/$librubya"; then > > dnl Workaround for the case where $librubyarg is set to > non-existent > > dnl libruby.a. Use the shared library instead. This happens > with Mac > > dnl OS X 10.3. > > librubyarg="-lruby" > > fi > > RUBY_LIBS="-L$rubylibdir $librubyarg $RUBY_LIBS" > > > > > > It is clear from the code above that RUBY_LIBS includes $librubyarg > which is to be set to '-lruby' if $librubyarg is libruby.a and if the file > $librubydir/$librubya does not exist, where $librubya is "libruby.a" for > 10.3. > > Apologies, my mistake. Didn't follow you code thoroughly enough. > > > So, when you ask someone for something, how about making more attempt to > make your questions look more well-posed or intelligent? > > If you are referring to me asking to substantiate your claim about OS X > 10.3, I see no way how that could look ill-posed or in-intelligent. > If you are referring to the thread itself, I'm under the assumption that I > didn't ask anything except discussing the possible implications of the > proposed patch; more than that, I simply submitted a proposal here with the > explanation of what are my reasons for believing this is a bug. That can be > clearly implied from the title and the original message. > > > Judging from the current state of discussion, I believe both patches are > viable. I don't see why you don't share this opinion. And I believe that > this discussion has been fruitful up to this point, but not enough to come > up with a definite and comprehensible argument for any of the given patches. > > My initial intention was to provide minimally invasive patch, that would > fix the problem once and for all, but I had my reservations about the whole > librubyarg/librubya thing, which seemed wrong and confusing to me (and > still does seem wrong). I feel like there is either something incorrect in > the logic here, or there were just too many corrections made, which > completely shadowed the initial logic and should be sorted out for good. > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
