Re: [Bug-gnulib] making it easier to import from gnulib

[Bruno Haible]

Karl Berry writes:

>     modules/
> 
> I'm not clear on when a file goes into modules/ and when into lib/,
> seems like <module>.am could go into modules.  I'd rather have the
> source dirs as clean as possible.

Good point. The <module>.am files don't need to be in lib/, they can
go elsewhere.

However, I think it's practical if the <module>.ac files live in m4/
because this makes it easier to look "who uses jm_PREREQ_XYZ" by doing
a "grep jm_PREREQ_XYZ m4/*".

> For that matter, instead of having lots of little files, how about
> having one file per module with all the necessary information about that
> module?

Tools like gnulibize get so simple when every kind of information is
in its own file. As soon as I put multiple things into one file, I
have to write parsers, worry about escaping backslashes etc. Since
gnulibize is just a special purpose tool, I wish to make it as easy
and flexible as possible. And lots of little files are the most
flexible approach.

Btw, if you don't like lots of little files, all you need is ReiserFS :-)

> Or even, since there really aren't that many modules, just put
> all the information into MODULES.txt.

On the contrary, it would be better to generate MODULES.txt (or
better: MODULES.html) from the little files. (Tools that parse
documentation that was written for humans are so hard to maintain.
Better the other way around.)

>    * gnulibize.
> 
> So a maintainer has gnulib checked out from cvs and runs gnulibize from
> there?  Sounds ok to me.

Yes that's how it's thought.

Bruno