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

RE: runtime/doc/tags not ignored

Expand Messages
  • Bovy, Stephen
    Yes This is especially relevant for platforms like IBM z/OS where auto-tools may not be available :) ... From: vim_dev@googlegroups.com
    Message 1 of 8 , Mar 8, 2013
    View Source
    • 0 Attachment
      Yes

      This is especially relevant for platforms like IBM z/OS where auto-tools may not be available :)

      -----Original Message-----
      From: vim_dev@... [mailto:vim_dev@...] On Behalf Of Taylor Hedberg
      Sent: Friday, March 08, 2013 8:03 AM
      To: vim_dev@...
      Subject: Re: runtime/doc/tags not ignored

      Benjamin R. Haskell, Fri 2013-03-08 @ 10:43:51-0500:
      > runtime/doc/tags probably shouldn't be in the repository in the first
      > place. Neither should src/auto/configure. Both of those things are
      > generated from other files that are in the repo.

      While it is true that configure scripts are generated from other source files, it is customary to commit them to version control anyway so that users can build the software without having to install and use Autotools.

      --
      --
      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
      ... The build process already generates the tag file (installrtbase rule), so that wouldn t be necessary. This sometimes causes the tag file to become dirty
      Message 2 of 8 , Mar 8, 2013
      View Source
      • 0 Attachment


        On Mar 8, 2013 10:12 AM, "Ben Fritz" <fritzophrenic@...> wrote:
        > Or are you asking WHY it's part of the repository?
        >
        > Probably to avoid the need of running :helptags after building Vim from source, but Bram would know that better. I like it, personally.

        The build process already generates the tag file (installrtbase rule), so that wouldn't be necessary.  This sometimes causes the tag file to become "dirty" if runtime files add tags but the committed tag file isn't updated.

        --
        --
        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.
         
         
      • Benjamin R. Haskell
        ... Sure. But that can be done as some kind of source release step, couldn t it? It s pretty common for there to be two kinds of source distributions:
        Message 3 of 8 , Mar 8, 2013
        View Source
        • 0 Attachment
          On Fri, 8 Mar 2013, Bovy, Stephen wrote:

          >> -----Original Message-----
          >> From: vim_dev@... [mailto:vim_dev@...] On Behalf Of Taylor Hedberg
          >> Sent: Friday, March 08, 2013 8:03 AM
          >> To: vim_dev@...
          >> Subject: Re: runtime/doc/tags not ignored
          >>
          >> Benjamin R. Haskell, Fri 2013-03-08 @ 10:43:51-0500:
          >>> runtime/doc/tags probably shouldn't be in the repository in the
          >>> first place. Neither should src/auto/configure. Both of those
          >>> things are generated from other files that are in the repo.
          >>
          >> While it is true that configure scripts are generated from other
          >> source files, it is customary to commit them to version control
          >> anyway so that users can build the software without having to install
          >> and use Autotools.
          >>
          > Yes
          >
          > This is especially relevant for platforms like IBM z/OS where auto-tools may not be available :)

          Sure. But that can be done as some kind of "source release" step,
          couldn't it? It's pretty common for there to be two kinds of source
          distributions: directly from revision control (where things that are
          generated aren't included, and there's some kind of "autogen.sh" script)
          and "snapshot", where a version that can be "./configure && make && sudo
          make install"'ed.

          I guess it's not that big a deal to have them in there. It's just
          annoying to have a 14,000 line file in the repo, virtually all of which
          changes if you try to regenerate it with a slightly-different version of
          autoconf.

          So... I'll drop the issue for configure.

          How about runtime/docs/tags? That one's generated by the doctags.c file
          in that same dir as part of a normal build.

          --
          Best,
          Ben

          --
          --
          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.
        • Tony Mechelynck
          ... I also use fetch --switch-parent but I have a local unnamed (topological) branch (inside the default -named- branch) which is merged at each fetch. It
          Message 4 of 8 , Mar 10, 2013
          View Source
          • 0 Attachment
            On 08/03/13 02:38, John Little wrote:
            > I have runtime/doc/tags in my .hgignore file, but most times I update with
            >
            > hg fetch --switch-parent
            >
            > I'm told
            >
            > abort: outstanding uncommitted changes
            >
            > so I run hg commit, and the changed comment says
            >
            > HG: changed runtime/doc/tags
            >
            > Why isn't this ignored?
            >
            > Regards, John Little
            >
            I also use fetch --switch-parent but I have a local unnamed
            (topological) branch (inside the default -named- branch) which is merged
            at each fetch. It contains a few small changes to .hgignore and
            src/feature.h; it also has runtime/doc/tags "deleted" (see hg help
            remove). Whenever there is a change to runtime/doc/tags on Bram's repo,
            the fetch asks me if I want to import or delete the file (Hint: if you
            are logging Mercurial output by |tee logfilename, then in order to see
            the prompt you need PYTHONUNBUFFERED set to some nonempty string in the
            environment: I use PYTHONUNBUFFERED=unbuffered) so I hit d<Enter> and
            everything goes well.

            Best regards,
            Tony.
            --
            Another bucket of what can only be described as human ordure hits
            ARTHUR.
            ARTHUR: ... Right! (to the KNIGHTS) That settles it!
            "Monty Python and the Holy Grail" PYTHON (MONTY)
            PICTURES LTD

            --
            --
            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.