On Jun 21, 2010, at 11:33 AM, devzero2000 wrote:
> On Mon, Jun 21, 2010 at 5:18 PM, Jeff Johnson <n3...@mac.com> wrote:
> What's likely not clear in the code is that aliases <-> execs
> (and options) need to converge to a common data structure
> with uniform parameters.
>
> It was clear to me, but I did not know the details. Some suggestions for
> proper implementation?
>
No specific suggestions for implementations.
Long answer:
However the general goal (and history) is pretty easy to describe.
POPT started life as a siimple argv option processor.
At some point alias/exec "feature" extensions were added. Since
these were additions, the "features" were "bolted on" to POPT.
I've managed to figure a poptItem data abstraction wrapper that
unifies the 3 major/primary data structures in POPT as a single entity.
That's essentially where popt-1.16 is today.
The flaws in the existing popt table <-> alias <-> exec unification are
all from
aliases/execs are not as completely defined as POPT table items
i.e. there's no strict analogue for POPT_ARGFLAG_FOO setting, nor
for "pointers" that are ultimately ELF symbols compiled into POPT tables.
So one reasonable extension would be to use dlsym (and the GNU
variant dlvsym if nexessary) to extend a "pointer" into at least POPT
aliases (popt exec's have rather more narrow functionality than tables/aliases).
Neither dlsym/dlvsym were part of POSIX when POPT was written and
so could not be "portably" used.
Short answer:
What's generally needed is no different than any spewage markup problem:
Enable interchange between markup <-> implementation to the
greatest
extent feasible.
Within POPT
aliases/execs == markup from configuration (like /etc/popt and
~/.poptrc)
implementation == the existing popt table items (and flimsy poptItem
abstraction)
Does that help?
73 de Jeff
