gather_docs() enhancement

Chad Kittel v3rt1g0 at lunar-linux.org
Mon Sep 20 00:22:49 UTC 2004


On Sunday 19 September 2004 04:26 pm, Auke Kok wrote:
> =^D
>
> code looks good, three questions:
>
> 1) did you test it properly and does it work?
It works in the "limited" testing that I have done with it. (a couple of hours 
of throwing different values at it and seeing what happens).  I would like 
another dev to really try it for themselfs to make sure I didn't overlook 
something stupid.

> 2) does it handle directories passed as argument properly?
handles directories being passed in when they are in the format of dirName/*
or dirName/FILENAME.  examples below

Here is a bunch of files in the src directory
READTHIS
HOWTOINSTALL
docs/example-setup
docs/html/index.html

If you would say
gather_docs READTH* HOWTOINSTALL docs/*

it would create this output in the module's document directory
READTHIS
HOWTOINSTALL
docs/example-setup

Note, it doesn't recurse into docs/html, one would have to add another 
paramter to gather_docs that said docs/html/*

I consider this a weekness of the code, and of anyone knows how to fix it, it 
would be appreciated...  Or maybe it's better to have finer control over what 
goes and what stays?

> 3) afaics it doesn't break old lunar/theedge cores if it's used in a
> module (right???) - double check
On old lunar/theedges, the only "Bad" part that can come of this is the fact 
that if the user has GARABGE=on and they lin a module that has a call to 
gather_docs; it will end up copying the DEFAULT files to the doc directory 
twice and the user will also be told twice that it happened. because it will 
just act like the old function which ignores paramters and copies the default 
docs.

> if you can answer both with 'yes' confidently I see no reason to keep it
> from lunar/theedge.  *HOWEVER*...
Once I get some feedback from another -dev who has tested this I will heed 
your advice.

Thank you.

> since the old code doesn't handle this correctly (although gracefully
> ignores the extra flags) we should consider bumping the UPDATED fields
> of lunar/theedge subsequently as this spreads around moonbase (tho I
> would give this a low priority of course). Still I don't see why this
> shouldn't go into theedge right away anyway
>
> sofar

- v3rt1g0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lunar-linux.org/mailman/private/lunar-dev/attachments/20040919/d46aa095/attachment.bin


More information about the Lunar-dev mailing list