Re: Re[2]: mmc patch

On Tuesday, January 28, 2003, at 09:29  AM, Cyb.org wrote:

> Tuesday, January 28, 2003, 9:57:23 AM, David wrote:
>> On Tuesday, January 28, 2003, at 12:40  AM, Cyb.org wrote:
>>> I suggest to create:
>>>   -c        - install into current dir
>>>   -l        - install into libexec
>>>   -p [path] - install into specified path
>>> or even rewrite MMC in C. What do you think?
>> Funny ... mmc used to be in C ... a long long time ago :) But I made
>> the decision that any app whose sole responsibility was to call a 
>> bunch
>> of other apps should probably be written in a shell scripting language
>> ... if only for ease of maintenance. I guess a -p option would work 
>> ...
>> I'm wondering though if we should just keep -i without the -p option
>> for now and maybe just rewrite it in perl down the road :) I'd hate to
>> make a sub-optimal interface decision here because of limitations in
>> the language mmc is written in.  What do you guys think ?
>
> C code would be more portable if we think about other OS, but anyway
> shell will be required if we want to compile something (I mean for
> example gcc on Windows cygwin/mingw), so we can stay with sh script.
> I think I'll do it like Cory says:
>
>  -i            - install into default libexec
>  -I <path>     - install into the specified path
>                  (can be absolute or relative)
>
> Agreed? ;)

If this is the consensus than I'm happy with it. I have three questions 
though

1) apxs which works a lot like mmc uses -i to specify installation, are 
there examples of  similar tools that use -I <path> to specify 
installation in a specific location?
2) configure scripts are sh scripts yet in the configure program I can 
say --with-apache or --with-apache=<path> . How do configure scripts 
accomplish this ?Do they use helper apps specifically for reading in 
arguments.
3) I lied :) This is in fact a multi-part question:
	3a) If both -i and -I <path> is specified what should happen ?
	3b) If only -I <path> is specified what should happen ?

> I suggest also:
>
>  -f            - force to overwrite if module exists in target place
>  -F            - don't overwrite if module exists in target place
>

Are both these options necessary or can we get by with only one of 
them? I agree with Cory and Shay when the say 'the fewer switches the 
better'. So in this case I think there is precedent for :

-f  - force to overwrite if module exists in target place
<default> - don't overwrite if module exists in target place

I would change mmc logic in the following way. If for some reason we 
cannot write out the module to the destination location either because 
it already exists there OR because we have no permission to write to 
that location then /tmp/mmc-XXX should not be deleted and we should 
output a message to that effect.

> if none of above is specified script will ask what to do.
> If -F will be set and module will exist in target then script will
> stop with appropriate comment.
>
>  -V            - show MMC version
>

Sounds good to me!

> Dave - do you know how to make $PROGVERSION variable in MMC right from
> CVS version?
>
Umm ... I know how to get the build date in :) and currently the 
version can be brought in from the configure script. I don't know how 
to get it directly from cvs though. I'd sure like to find out! Having 
the version strings in autoconf scripts just sucks.

-Dave

> Cyb.org
>
>