Re: [gnulib-tool-py] --add-import and --remove-import options

[Bruno Haible]

Hi Dmitriy,

> In help message there is section which describes --source-base, m4-base,
> etc. While parameter --lib has its default value ('libgnu'), what will be
> the default values for *base options? Help says that default value for
> --source-base is "Directory relative to --dir where source code is placed
> (default "lib").", but what does that mean? "lib" directory inside current
> package or inside gnulib?

I have written up an explanation in wiki now:
  https://github.com/ghostmansd/gnulib-python/wiki/Directories

You find superficial default values of the options in the original gnulib-tool,
lines 962..1000. The real default values depend on the mode, see
  - lines 5604..5612 for --create-testdir,
  - lines 6303..6379 for --import/--add-import/--remove-import/--update.

For example, if someone specifies --source-base=gl/lib, and the
--dir=$HOME/projects/hello, then the directory into which *.[ch] files
will be copied is $HOME/projects/hello/gl/lib.

> BTW, wouldn't it be better to use absolute paths instead of relative ones?
> I've seen a couple of functions which works on relative paths, but wouldn't
> it be better to transform relative path to absolute using os.path.realpath
> (e.g. os.path.realpath('../../'))? This makes the things easier.

No, this would not be so good:

  1) Converting a relative file name to an absolute one and then accessing
     the file or directory through the absolute one requires a readable
     directory. There are cases (such as security reasons) where people
     want to work in directories which are "hidden from above", that is,
     where absolute file names don't work.

  2) In some cases, gnulib-tool writes file names into files. It is better
     not to put absolute file names into such places, because they reveal
     where gnulib-tool has been executed. For example, if the directory name
     is /nfs/esa/darmstadt/jem/hello, it would become undeniable for the
     hypothetical user 'jem' in ESA Darmstadt that he ran gnulib-tool on
     these machines.

  3) On Windows, a relative file name has simpler syntax than an absolute
     one. Absolute ones are of the form a:/foo or a:\foo, which is more
     complicated.

In the old gnulib-tool, we never access $m4base/somefile. We always access
$destdir/$m4base/somefile. If you are consequent and always prepend
$destdir to any file system access that implies $m4base (or $sourcebase etc.),
there is no problem.

Bruno