[sword-devel] osis2mod change

[DM Smith]

On Sep 27, 2007, at 1:49 PM, Troy A. Griffitts wrote:

> DM,
>
> I'm sorry.  I never intended to 'stifle community contribution'.  I  
> was
> merely trying to make a technical decision.  If you describe to me a
> benefit of importing 475 lines which we did not write or have any idea
> if it is crossplatform-- to check 4 command line options to a tool  
> that
> is only total 840 lines, then I might consider.

You asked for one. Here is a bunch.

Pros:
Industry standard command line code.
Reusable code.
Becomes a pattern for new utilities, perhaps for existing utilities.
Stable/proven code.
POSIX standard.
Usage is well-known,  understood and used by many programmers.
Easy to use.
Easy to maintain.
Easy to extend.
Favorable license.

Cons:
Would need to be proven on various platforms.
Not invented here.


>   But it seems to me we
> could simple add a 20 line for loop to do the same.  And I'm not  
> sure we
> wouldn't still need to add the 20 line for loop if we imported this
> code.  Checking commandline arguments in C is not that hard.  I don't
> need a library to do it for me-- especially when our input  
> arguments are
> neither lengthy, nor complex.

Yes, checking command line options is not all that hard in C. But why  
reinvent the wheel?

create a loop that
checks first characters of argument for - or --,
look for match against expected set of values
when match found determine whether it requires an argument,
if so get the argument and determine how to convert it to an  
appropriate internal representation
based upon what was successfully passed determine whether  
disambiguation needs to occur,
if so, disambiguate, saving value as appropriate.
on error, report error and post usage statement.

Granted some of the above needs to be done regardless of which  
implementation is used.


>
> Please understand I'm only trying to make a technical decision.

Another reason, I have further plans to enhance osis2mod to also take  
a valid OSIS commentary. I'm anticipating that will require more flag  
changes. Also, with Chris' change to do normalization, it may be  
necessary to pass in whether the encoding is UTF-8 or Latin-1.

>
> 	-Troy.
>
>
>
> DM Smith wrote:
>> Troy,
>>
>> I'm not sure what the dependency would be. The code is self-contained
>> and 475 lines. The getsubopt.c is not needed unless getopt.h is  
>> used as
>> is. As Chris notes, it can be isolated in the utilities directory not
>> injecting dependency anywhere. The only other possible dependency is
>> that of the license. If that is a problem, I will keep looking for a
>> version with one that is not.
>>
>> Please don't stifle community contribution.
>>
>> DM
>>
>> Troy A. Griffitts wrote:
>>> I think I would like to conclude this thread with deciding that  
>>> we are
>>> not willing to introduce a dependency to iterate simple program  
>>> args.
>>> Thank you all for the suggestion.
>>>
>>> 	-Troy.
>>>
>>>
>>>
>>> DM Smith wrote:
>>>
>>>> How about this implementation, as it is pretty short:
>>>>
>>>> Header:
>>>> http://www.mirbsd.org/cvs.cgi/src/include/getopt.h? 
>>>> rev=1.1.1.1;content-type=text%2Fplain
>>>>
>>>> Code:
>>>> http://www.mirbsd.org/cvs.cgi/src/lib/libc/stdlib/getopt_long.c? 
>>>> rev=1.1.1.3;content-type=text%2Fplain
>>>> http://www.mirbsd.org/cvs.cgi/src/lib/libc/stdlib/getsubopt.c? 
>>>> rev=1.3;content-type=text%2Fplain
>>>>
>>>> It is a BSD license that is compatible with GPL (some BSD are  
>>>> not) and
>>>> it is self contained in one file.
>>>>
>>>> -- DM
>>>>
>>>>
>>>>
>>>> On Sep 26, 2007, at 5:15 PM, Chris Little wrote:
>>>>
>>>>
>>>>> But Windows lacks it, I believe.
>>>>> I suppose we could absorb some BSD code, assuming it were  
>>>>> short, to
>>>>> achieve the same end, but we can't just #include <unistd.h>.
>>>>>
>>>>> --Chris
>>>>>
>>>>> Sergio QUEIROZ wrote:
>>>>>
>>>>>> getopt without GNU extensions is a part of the Unix Base  
>>>>>> Specifications
>>>>>> and should be available mostly everywhere.
>>>>>>
>>>>>> http://www.opengroup.org/onlinepubs/009695399/functions/ 
>>>>>> getopt.html
>>>>>>
>>>>>> Yours,
>>>>>>
>>>>>> Sergio
>>>>>>
>>>>>> Le mercredi 26 septembre 2007 à 11:35 -0700, Chris Little a  
>>>>>> écrit :
>>>>>>
>>>>>>> Eeli Kaikkonen wrote:
>>>>>>>
>>>>>>>> On Tue, 25 Sep 2007, Troy A. Griffitts wrote:
>>>>>>>>
>>>>>>>>> As DM has said previously, it
>>>>>>>>> would be really nice to have normal -options which are not  
>>>>>>>>> order
>>>>>>>>> dependent.
>>>>>>>>>
>>>>>>>> Using GNU getopt?
>>>>>>>> http://www.gnu.org/software/libc/manual/html_node/Getopt.html
>>>>>>>>
>>>>>>> Using anything from GNU would be a bad idea. Enduring "the chore
>>>>>>> involved in parsing typical unix command line options" makes  
>>>>>>> our code
>>>>>>> more portable and avoids the need to license additional  
>>>>>>> libraries.
>>>>>>>
>>>>>>> Writing a simple command line option parser isn't especially  
>>>>>>> difficult
>>>>>>> or burdensome, anyway.
>>>>>>>
>>>>>>> --Chris
>>>>>>>
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page