Re: [gnulib-tool-py] Update .gitignore and .cvsignore files

[Bruno Haible]

Hi Dmitriy,

> I'm glad to tell you that GLImport is almost finished.

Yes, I see huge commits. Wow!!

> After generation of the tests Makefile diff shows no difference between
> pygnulib and gnulib-tool.sh. I use the following scheme:
> 
> ls
>   gnulib/ gnulib-python
> mkdir m4-bash
> mkdir m4-python
> cp -rf m4 m4-bash
> cp -rf m4 m4-python
> 
> # args for gnulib-tool.sh are
> # given using command-line.
> # args for pygnulib are given
> # using gnulib-tool.py.
> cd m4-bash
> bash ../gnulib-tool --add-import javaexec-script > ../sh
> cd ..
> cd m4-python
> python gnulib-tool.py > ../py
> cd ..
> diff -ru m4-bash m4-python
> diff -u sh py

Perfect! And thanks for showing this recipe.

But I'm confused about the argument passing. I thought we would at some
point also use sys.argv. So far only sys.argv[0] appears to be used.
I imagined that we would have
  1) for Python-style calls: a GLConfig constructor that takes
     destdir...dryrun as Python objects,
  2) for invocations from shell / command-line: an argv parser that
     understands the same syntax as gnulib-tool in shell. I thought
     you wanted to use argparse for this purpose, and the only issue
     was whether the --help message could be generated by argparse or
     had to be hand-written. Now I don't see a use of argparse.ArgumentParser.
     Huh?

> The last thing I need to do is to write some code about vc_files and
> reminders about includes. While the second seems to be easy, the first
> is hard enough. May be it will be better if you just describe what we
> need to get as result: experience shows that it can be better than just
> to rewrite the entire code.

OK. --vc-files and --no-vc-files are options, made persistent in
gnulib-cache.m4 through a gl_VC_FILES syntax, that tell whether gnulib-tool
should create or update .cvsignore and .gitignore files.
This is an option because there are different use-cases, see the documentation
at <http://www.gnu.org/software/gnulib/manual/html_node/VCS-Issues.html>

The processing of vc_files occurs only in --import, --add-import,
--remove-import, --update modes. What does this processing do?
It is ugly in the shell code because in shell we don't have real data
structures.

It takes
  a) the list of added files (plus the $m4base/gnulib-comp.m4 file),
  b) the list of removed files.

Then it sorts this list of files
  - first sort priority is the directory in which the file is,
  - second sort priority is the added vs. removed status,
  - thirs sort priority is the basename (filename without directory).
After this sorting it processes the list, directory by directory. For
each directory:
  - It collects the list of added files (variable last_dir_added)
    and the list of removed files (variable last_dir_removed).
  - If CVS is enabled (this is determined by looking whether a 'CVS'
    directory exists in $destdir or in the specific directory
    or whether a '.cvsignore' file exists in the specific directory),
    then .cvsignore is updated as follows:
    - If .cvsignore already exists:
      - For each added file basename, see whether it's already in the
        .cvsignore.
        If yes, we don't need to add it a second time.
      - For each removed file name, the code does the same thing. This
        makes no sense; looks like a bug.
      - The list of added file basenames is added at the end of the .cvsignore.
      - The lines of .cvsignore that match removed file basenames are removed
        from .cvsignore.
      - A backup of .cvsignore is created in '.cvsignore~'.
    - If .cvsignore does not exist:
      - A new .cvsignore is created, consisting of '.deps', '.dirstamp',
        and the list of added file basenames.
  - If git is enabled (this is determined by looking whether a '.git'
    directory exists in $destdir or whether a '.gitignore' file exists
    in the specific directory), then .gitignore is updated in the same way,
    except that .gitignore usually contains a / before each basename:
      /foo          designates file 'foo' in the current directory
      foo           designates file 'foo' in the current directory and every
                    subdirectory.
    So for each added file basename, we add "/basename" not just "basename",
    and when a file is removed, we remove "/basename" from the list, not
    "basename".

> It's a pity, however, that I don't have a time to update timeline.

That's not a problem. At the end, now, you have a good perception what
is missing and what you need to do next. The timeline was most important
1-2 months ago, when it was hard to have an overview of the pieces that
need to be done.

Bruno