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

[Karl Berry]

    However, I think it's practical if the <module>.ac files live in m4/

I agree.

    have to write parsers, worry about escaping backslashes etc. Since

I imagining the "parsing" being done with something as simple as
awk '$1=="'$module'" {$print $2}'
You don't have to escape any backslashes.  Just make the input format as
easy as you need to parse.

    And lots of little files are the most flexible approach.

>From the point of view of writing the tool, sure.  But from the point of
view of a programmer trying to use gnulib, it seems to me it would be
far easier to learn what's what when the information is gathered in one
place -- I know it would be for me, anyway.

When it's scattered into N different files, you have to understand the
purpose of each file and how they fit together, you're never sure if
there's N+1'st file you haven't found yet, etc.

I can see that actual definitions of autoconf macros and the like are
best kept in a separate file, because that's potentially many lines of
programming.  But for files that are always (or almost always) one line,
and just listing names, like module.ac or module.am (as I understand it,
maybe I'm missing some aspects of your proposal), it seems easy enough
to put them into one file, for instance, modules.txt could have lines
like this:

closeout.dep: foo bar
closeout.dep: baz
closeout.ac: gnulib_CLOSEOUT
closeout.am: whatever

nextmodule.dep: blah
...

(closeout.m4 would still be a separate file.)

    On the contrary, it would be better to generate MODULES.txt (or

I guess I didn't say so explicitly, but I figured modules.txt would also
get different syntax.  I certainly agree it would be irrational to try
to parse modules.txt in its current human-oriented syntax.


Anyway, since you're volunteering to do the work, I think you have the
final say :).  Certainly any method will suffice.