[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: argp spec
From: |
Niels Möller |
Subject: |
Re: argp spec |
Date: |
12 Sep 2002 11:56:36 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Miles Bader <address@hidden> writes:
> Does this mean you could get rid of the memory allocation in the parser?
> [That was one thing I though might be possible with a `native' parser,
> since it could just walk the data-structures passed in by the user
> during parsing.]
I'm not sure, the parser allocates a block of memory when it is
initialized (it's organized the same way as the glibc version, with
parser "groups" etc). I guess one could allocate that state on the
stack instead. Then there's memory allocation in the argp-ftmstream.c
and argp-help.c, which I haven't had any reason to touch or read
carefully.
The groups are organized as a linear array which corresponds to
pre-order trversal of the argp tree. One could traverse the tree
directly, but I haven't tried doing that. I suspect that there's still
some state that must be allocated somewhere.
> If we make a more standard drop-in version of argp, what would your
> requirements be for using it in lsh?
Currently I have argp in subdirectory with it's own configure.ac and
Makefile.am. The parent configure.ac checks for an existing and
working argp on the system, then (unconditionally) calls
AC_CONFIG_SUBDIR(src/argp). So argp is always built, but the lsh
programs will link to it (using the name "src/argp/libargp.a") only if
the configure test indicated that the system's argp isn't good enough.
The argp library is never installed on the system, it's listed in
noinst_LIBRARIES in the Makefile.am. I also don't try to build any
shared libraries (it's complex to do portably, and I don't
particularly like libtool).
It would be nice to skip building argp if it's not needed, but except
for that, I think this organization is just what is needed.
And it's trivial to make a standalone argp distribution from it, just
change Makefile.am so that it wants to install the library, and run
make dist.
> As I mentioned in my previous message I'm think of something like the
> libc glob code, where you can basically just copy a directory into your
> source tree for distribution, and it will contains its own configure and
> Makefile file &c., which you can call from your configure/Makefile, and
> it would install a static library <somewhere> in the build tree for you
> to link against.
That's close to what I do, except that no install target is involved,
I just link to the library file in the directory where it was built.
Regards,
/Niels