In researching the best option to normalize the amount of arguments
we pass to the current pilot-link conduits, three possible avenues came to
light: getopt(), getopt_long(), and popt(). Each has their own benefits and
advantages.
Using getopt() and getopt_long() as we are now in a pseudo-real
capacity can continue, and for systems like Solaris and OSX which do not
contain getopt_long(), we can link the required functions statically into
the binaries which require it (local getopt.h/getopt.c).
popt(), although not yet common or "standardized" yet offers us
quite a bit more flexibility than the current getopt() gstyle argument
parsing. I'm going to investigate both functionally, since right now all of
the top-level binaries are using getopt() and have been corrected to accept
similar and consistant arguments. Some of the benefits are:
1. It is fully reentrant. It does not utilize global variables, thus
enabling multiple passes in parsing argv.
2. It can parse an arbitrary array of argv-style elements, allowing
parsing of command-line-strings from any source.
3. It provides a standard method of option aliasing.
4. It can exec external option filters
5. It can automatically generate help and usage messages for the
application.
6. It supports argument typing.
The question though, is that popt() contains an MIT/X Consortium
License. It is not GPL or LGPL, but it is compatible, and we can link to it.
Adding a local ./popt source to the pilot-link package for systems which do
not contain their own will increase the size of the tarball by about 100k
(after removing some of the larger unnecessary files from the popt source
package itself, such as intl/po catalogs and so on, which mostly can be
removed since PalmOS doesn't support the number of languages that i18n
supports, currently).
If popt() proves to be viable, and gives us actual real-world
benefits, is there any objection to including this with pilot-link, or
building a dependancy on it within pilot-link? Or should be stick with
getopt() and friends, and maintain local copies and portability?
I'm open to using anything, but portability and flexibility are
absolute requirements.
/d
_______________________________________________
Pilot-unix mailing list
[EMAIL PROTECTED]
http://hcirisc.cs.binghamton.edu/mailman/listinfo/pilot-unix
