Loading ...
Sorry, an error occurred while loading the content.

Vim's Ruby version detection breaks on Fedora 19

Expand Messages
  • Michael Henry
    All, On Fedora 19, Vim s configure script no longer correctly detects the version of Ruby. Vim s current algorithm involves the Ruby expression
    Message 1 of 6 , Aug 3, 2013
    • 0 Attachment
      All,

      On Fedora 19, Vim's configure script no longer correctly detects
      the version of Ruby. Vim's current algorithm involves the Ruby
      expression ``RbConfig::CONFIG['ruby_version']``, which returns a
      string such as "1.9.1" on Fedora 17. On Fedora 19, the above
      Ruby expression returns an empty string.

      It appears to me that this is due to a change in Fedora. In the
      ticket linked below, the maintainer asserts that querying
      ``ruby_version`` is incorrect, as that variable can have
      arbitrary contents:
      https://bugzilla.redhat.com/show_bug.cgi?id=923703#c1

      Empirically, I can verify that the behavior has changed. On
      Fedora 17, the query works:

      $ ruby -r rbconfig -e "puts RbConfig::CONFIG['ruby_version']"
      1.9.1

      On Fedora 19, this same query prints the empty string.

      The following patch changes the Ruby version detection algorithm
      to check the ``VERSION`` and ``RUBY_VERSION`` variables as used
      earlier in Vim's configure script. Essentially, the query
      becomes::

      $ ruby -e "puts ((VERSION rescue RUBY_VERSION))"
      1.9.3

      This works on Fedora 19 as well::

      $ ruby -e "puts ((VERSION rescue RUBY_VERSION))"
      2.0.0

      Given that Vim's configure script relies on this same check
      to ensure the version is at least "1.6.0", it seems reasonable
      to me to use this algorithm (though I'm no Ruby expert).


      Here is the patch against Vim 7.4.14:

      $ diff -Naur vim-7.4/src/auto/configure{.orig,}
      --- vim-7.4/src/auto/configure.orig 2013-08-03 20:00:13.595912341 -0400
      +++ vim-7.4/src/auto/configure 2013-08-03 20:02:11.269574272 -0400
      @@ -6740,7 +6740,7 @@
      if test -d "$rubyhdrdir/$rubyarch"; then
      RUBY_CFLAGS="$RUBY_CFLAGS -I$rubyhdrdir/$rubyarch"
      fi
      - rubyversion=`$vi_cv_path_ruby -r rbconfig -e "print
      $ruby_rbconfig::CONFIG['ruby_version'].gsub(/\./, '')[0,2]"`
      + rubyversion=`$vi_cv_path_ruby -e "print ((VERSION rescue
      RUBY_VERSION)).gsub(/\./, '')[0,2]"`
      RUBY_CFLAGS="$RUBY_CFLAGS -DRUBY_VERSION=$rubyversion"
      rubylibs=`$vi_cv_path_ruby -r rbconfig -e "print
      $ruby_rbconfig::CONFIG['LIBS']"`
      if test "X$rubylibs" != "X"; then


      Thanks,
      Michael Henry

      --
      --
      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 vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • James McCoy
      ... Notice how the version number here doesn t match the version number in the previous command? RbConfig::CONFIG[ ruby_version ] reports the API version,
      Message 2 of 6 , Aug 3, 2013
      • 0 Attachment
        On Sat, Aug 03, 2013 at 08:29:06PM -0400, Michael Henry wrote:
        > Empirically, I can verify that the behavior has changed. On
        > Fedora 17, the query works:
        >
        > $ ruby -r rbconfig -e "puts RbConfig::CONFIG['ruby_version']"
        > 1.9.1
        >
        > On Fedora 19, this same query prints the empty string.
        >
        > The following patch changes the Ruby version detection algorithm
        > to check the ``VERSION`` and ``RUBY_VERSION`` variables as used
        > earlier in Vim's configure script. Essentially, the query
        > becomes::
        >
        > $ ruby -e "puts ((VERSION rescue RUBY_VERSION))"
        > 1.9.3

        Notice how the version number here doesn't match the version number in
        the previous command? RbConfig::CONFIG['ruby_version'] reports the API
        version, while VERSION/RUBY_VERSION report the release version.

        $ ruby --version
        ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
        $ ruby -e 'puts ((VERSION rescue RUBY_VERSION))'
        1.9.3
        $ ruby -r rbconfig -e "puts RbConfig::CONFIG['ruby_version']"
        1.9.1

        What Vim needs to know is the API version, not the release version.

        Cheers,
        --
        James
        GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan@...>
      • Michael Henry
        ... Thanks - that s informative. Would RUBY_VERSION and ruby_version ever differ in their major.minor values? Vim s configure script concatenates the major
        Message 3 of 6 , Aug 3, 2013
        • 0 Attachment
          On 08/03/2013 08:59 PM, James McCoy wrote:
          > Notice how the version number here doesn't match the version number in
          > the previous command? RbConfig::CONFIG['ruby_version'] reports the API
          > version, while VERSION/RUBY_VERSION report the release version.
          >
          > $ ruby --version
          > ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
          > $ ruby -e 'puts ((VERSION rescue RUBY_VERSION))'
          > 1.9.3
          > $ ruby -r rbconfig -e "puts RbConfig::CONFIG['ruby_version']"
          > 1.9.1
          >
          > What Vim needs to know is the API version, not the release version.

          Thanks - that's informative. Would RUBY_VERSION and
          ruby_version ever differ in their major.minor values? Vim's
          configure script concatenates the major and minor number to get
          a single integer (19 or 20 for 1.9.x or 2.0.y), ignoring the
          third number entirely. If the API and release versions can
          differ in their major.minor value, then as you say, this patch
          to use RUBY_VERSION wouldn't work. If there is not another way
          to query the API version (which I could believe), then it seems
          that Fedora 19's build of Ruby is broken, since 'ruby_version'
          is set to an empty string on that platform::

          [root@fedora19 ~]# ruby -r rbconfig -e "puts
          RbConfig::CONFIG['ruby_version']"

          [root@fedora19 ~]#

          I'm not very familiar with Ruby, so before I reopen the below
          Fedora ticket (which the maintainer marked "CLOSED NOTABUG"),
          would you be able to point me at some official Ruby
          documentation that requires 'ruby_version' to contain something
          useful? My searching didn't show anything I could recognize as
          authoritative.

          This is the Fedora ticket in question:
          https://bugzilla.redhat.com/show_bug.cgi?id=923703

          The comment from the maintainer is:

          """
          From Vít Ondruch 2013-03-20 07:10:25 EDT

          You are right. That is coming into that place due to
          "--with-ruby-version=''" configuration option. Since you can
          specify there any arbitrary string (if I am not mistaken) using
          that option, I don't think you get what you want.

          I am going to reject this issue. If you disagree then we can
          consider upstream report. Also, if you provide me with your use
          case, we might find some better option.
          """

          I don't understand why Vít talks about an "upstream report",
          since that makes it seems like something the Ruby project itself
          would need to address; but if Ruby installations are expected to
          provide an API version for 'ruby_version' and I can point at
          some documentation that says so, I'll reopen the Fedora ticket.

          Thanks for any help,
          Michael Henry

          --
          --
          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 vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Bram Moolenaar
          ... How about only using the VERSION when the other one is empty? Does this work for you or generate some error (in src/auto/configure):
          Message 4 of 6 , Aug 4, 2013
          • 0 Attachment
            Michael Henry wrote:

            > On 08/03/2013 08:59 PM, James McCoy wrote:
            > > Notice how the version number here doesn't match the version number in
            > > the previous command? RbConfig::CONFIG['ruby_version'] reports the API
            > > version, while VERSION/RUBY_VERSION report the release version.
            > >
            > > $ ruby --version
            > > ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
            > > $ ruby -e 'puts ((VERSION rescue RUBY_VERSION))'
            > > 1.9.3
            > > $ ruby -r rbconfig -e "puts RbConfig::CONFIG['ruby_version']"
            > > 1.9.1
            > >
            > > What Vim needs to know is the API version, not the release version.
            >
            > Thanks - that's informative. Would RUBY_VERSION and
            > ruby_version ever differ in their major.minor values? Vim's
            > configure script concatenates the major and minor number to get
            > a single integer (19 or 20 for 1.9.x or 2.0.y), ignoring the
            > third number entirely. If the API and release versions can
            > differ in their major.minor value, then as you say, this patch
            > to use RUBY_VERSION wouldn't work. If there is not another way
            > to query the API version (which I could believe), then it seems
            > that Fedora 19's build of Ruby is broken, since 'ruby_version'
            > is set to an empty string on that platform::
            >
            > [root@fedora19 ~]# ruby -r rbconfig -e "puts RbConfig::CONFIG['ruby_version']"
            >
            > [root@fedora19 ~]#

            How about only using the VERSION when the other one is empty? Does this
            work for you or generate some error (in src/auto/configure):

            rubyversion=`$vi_cv_path_ruby -r rbconfig -e "print $ruby_rbconfig::CONFIG['ruby_version'].gsub(/\./, '')[0,2]"`
            if test "X$rubyversion" = "X"; then
            rubyversion=`$vi_cv_path_ruby -e "print ((VERSION rescue RUBY_VERSION)).gsub(/\./, '')[0,2]"`
            fi


            > I'm not very familiar with Ruby, so before I reopen the below
            > Fedora ticket (which the maintainer marked "CLOSED NOTABUG"),
            > would you be able to point me at some official Ruby
            > documentation that requires 'ruby_version' to contain something
            > useful? My searching didn't show anything I could recognize as
            > authoritative.
            >
            > This is the Fedora ticket in question:
            > https://bugzilla.redhat.com/show_bug.cgi?id=923703
            >
            > The comment from the maintainer is:
            >
            > """
            > >From Vít Ondruch 2013-03-20 07:10:25 EDT
            >
            > You are right. That is coming into that place due to
            > "--with-ruby-version=''" configuration option. Since you can
            > specify there any arbitrary string (if I am not mistaken) using
            > that option, I don't think you get what you want.
            >
            > I am going to reject this issue. If you disagree then we can
            > consider upstream report. Also, if you provide me with your use
            > case, we might find some better option.
            > """
            >
            > I don't understand why Vít talks about an "upstream report",
            > since that makes it seems like something the Ruby project itself
            > would need to address; but if Ruby installations are expected to
            > provide an API version for 'ruby_version' and I can point at
            > some documentation that says so, I'll reopen the Fedora ticket.
            >

            --
            hundred-and-one symptoms of being an internet addict:
            49. You never have to deal with busy signals when calling your ISP...because
            you never log off.

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ an exciting new programming language -- http://www.Zimbu.org ///
            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

            --
            --
            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 vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • Bram Moolenaar
            ... Thanks. I cannot think of a reason to first check for the Ruby version one way and then another way. It works on my system as well. -- hundred-and-one
            Message 5 of 6 , Aug 4, 2013
            • 0 Attachment
              Michael Henry wrote:

              > On Fedora 19, Vim's configure script no longer correctly detects
              > the version of Ruby. Vim's current algorithm involves the Ruby
              > expression ``RbConfig::CONFIG['ruby_version']``, which returns a
              > string such as "1.9.1" on Fedora 17. On Fedora 19, the above
              > Ruby expression returns an empty string.
              >
              > It appears to me that this is due to a change in Fedora. In the
              > ticket linked below, the maintainer asserts that querying
              > ``ruby_version`` is incorrect, as that variable can have
              > arbitrary contents:
              > https://bugzilla.redhat.com/show_bug.cgi?id=923703#c1
              >
              > Empirically, I can verify that the behavior has changed. On
              > Fedora 17, the query works:
              >
              > $ ruby -r rbconfig -e "puts RbConfig::CONFIG['ruby_version']"
              > 1.9.1
              >
              > On Fedora 19, this same query prints the empty string.
              >
              > The following patch changes the Ruby version detection algorithm
              > to check the ``VERSION`` and ``RUBY_VERSION`` variables as used
              > earlier in Vim's configure script. Essentially, the query
              > becomes::
              >
              > $ ruby -e "puts ((VERSION rescue RUBY_VERSION))"
              > 1.9.3
              >
              > This works on Fedora 19 as well::
              >
              > $ ruby -e "puts ((VERSION rescue RUBY_VERSION))"
              > 2.0.0
              >
              > Given that Vim's configure script relies on this same check
              > to ensure the version is at least "1.6.0", it seems reasonable
              > to me to use this algorithm (though I'm no Ruby expert).
              >
              >
              > Here is the patch against Vim 7.4.14:

              Thanks. I cannot think of a reason to first check for the Ruby version
              one way and then another way. It works on my system as well.


              --
              hundred-and-one symptoms of being an internet addict:
              48. You get a tatoo that says "This body best viewed with Netscape 3.1 or
              higher."

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ an exciting new programming language -- http://www.Zimbu.org ///
              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

              --
              --
              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 vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            • Michael Henry
              ... $ruby_rbconfig::CONFIG[ ruby_version ].gsub(/ ./, )[0,2] ` ... RUBY_VERSION)).gsub(/ ./, )[0,2] ` ... Yes, this works fine for me. It seems like a
              Message 6 of 6 , Aug 4, 2013
              • 0 Attachment
                On 08/04/2013 02:07 PM, Bram Moolenaar wrote:
                > How about only using the VERSION when the other one is empty? Does this
                > work for you or generate some error (in src/auto/configure):
                >
                > rubyversion=`$vi_cv_path_ruby -r rbconfig -e "print
                $ruby_rbconfig::CONFIG['ruby_version'].gsub(/\./, '')[0,2]"`
                > if test "X$rubyversion" = "X"; then
                > rubyversion=`$vi_cv_path_ruby -e "print ((VERSION rescue
                RUBY_VERSION)).gsub(/\./, '')[0,2]"`
                > fi

                Yes, this works fine for me. It seems like a good work-around
                to me.

                Thanks,
                Michael Henry

                --
                --
                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 vim_dev+unsubscribe@....
                For more options, visit https://groups.google.com/groups/opt_out.
              Your message has been successfully submitted and would be delivered to recipients shortly.