On Tue, Jan 17, 2006 at 12:00:31PM +0100, H.Merijn Brand wrote: > On Tue, 17 Jan 2006 09:54:53 +0000, Tim Bunce <[EMAIL PROTECTED]> wrote: > > > On Tue, Jan 17, 2006 at 10:06:36AM +0100, H.Merijn Brand wrote: > > > > > > I also suggest to make a new sub-folder with the examples of all the > > > config.sh's, perl -V lists and Makefiles as separate files. Not only that > > > makes it easier to copy/alter these files for personal use, but also > > > shortens the documentation, and causes less clutter for people not > > > interested in the already outdated examples. > > > > Good idea. Looks like you're doing a great job so I'm happy to go with > > whatever you'd recommend. HP-UX users (not me) may have specific suggestions > > but I'll let you make the decisions on this one. > > Since it has no real hurry, and I'm a bit short in time, I'd like to get some > more comment on this here, and then I think I can volunteer to come up with a > patch that does so for all README's that include examples like the above > > The question then would be what a logical name would be > > - config-files - code_snippets > - example-files - miscelanious > - README-files - files > > If this were to be only for the README support, I'd choose README-files, and > then make files like hpux-11.23-5.8.8-gcc-Makefile-1, > hpux-10.20-5.6.0-cc-perl-V, etc > > But where does that end? Does it have to include all versions of OS, perl, > DBI, DBD-Oracle? Does every file name have to reflect the compiler used? > > Or do we make hpux-Makefile-1, hpux-Makefile-2, aix-config.sh-1, etc and make > a README or INDEX file that makes a two line description per file, or a > matrix or ...
Woha! Let's not over-engineer this but just aim for baby steps that move us along in the right direction. One OS at a time. The problems that READMEs address naturally tend to be nasty and not well suited to a regular structure. We should aim to just help the humans help themselves. Having README.hpux.txt containing an overview and referring to specific README-files/hpux/* files for further details on specific issues seems like a good plan. Tim.
