bug-gnu-utils
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]