[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnulib-tool-py] --add-import and --remove-import options
From: |
Bruno Haible |
Subject: |
Re: [gnulib-tool-py] --add-import and --remove-import options |
Date: |
Sat, 05 May 2012 00:19:21 +0200 |
User-agent: |
KMail/4.7.4 (Linux/3.1.10-1.9-desktop; KDE/4.7.4; x86_64; ; ) |
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