bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Plain text matching with regex: RE_PLAIN


From: Bruno Haible
Subject: Re: Plain text matching with regex: RE_PLAIN
Date: Sun, 19 Sep 2010 15:33:47 +0200
User-agent: KMail/1.9.9

Hello Reuben,

> Some questions, having read the documentation:
> 
> 1. There doesn't seem to be a default value for --local-dir. I used
> local-lib; is there a recommended value?

I use --local-dir=gnulib-local; others use --local-dir=gl/override or
--local-dir=gl.

> It would be nice to have a default, both to encourage compatible naming
> and to avoid the need for --local-dir when the default value is used.

I disagree. Similar naming is not a goal; everyone is free to name the
directories in his package the way he likes. And --local-dir is a very
important option; it shouldn't be implicit. Additionally, we want to
allow multiple --local-dir options in the future.

> 2. There's a remark that is unclear to me: "(This kind of kitchen-sink
> module is not needed when you
> use the @command{gnulib-tool} option @samp{--makefile-name}.)" How
> does --makefile-name help in this case?

It doesn't force you to move stuff that you would have written in a
Makefile.am in a gnulib module description; it allows you to keep the
Makefile.am like you originally wanted.

> 3. It seems to me that the structure of this section of the
> documentation could be clearer: in particular, it seems that all the
> things listed that you "can do" to add local code are, rather than
> fixed options, consequences of the file override rules listed below.
> Hence, I suggest reordering the page to first explain the rule, and
> then say that "as a result, you can..." and list the things you can
> do, which are effectively recommended ways to exploit the file
> overrides (there may be other good ways, or other bad ways).

People try to read a minimum of documentation usually. They don't want
to read details just to understand a little later what they can use them
for. For this reason, I write documentation on purpose in a way that
presents first the possible uses and then only the gory details. (At
least for those pieces of software where the uses are limited.)
First I answer the question "What can I do with this software?",
then only the question "How do I do it?"

Bruno



reply via email to

[Prev in Thread] Current Thread [Next in Thread]