On Mon, Dec 17, 2007 at 01:03:46PM -0500, Jeff Squyres <[EMAIL PROTECTED]>
wrote:
> Is there any intent to make libev be a fully-embeddable project? Such
> as:
How about reading the documentation, especially the section "EMBEDDING"?
:)
> - having the majority of libev's configure script in an m4 macro that
> can be invoked from a higher-level configure script
Thats how it is done: the configure script contains no configuration apart
from the parts not used for embedding, e.g. AC_PROG_LIBTOOL, AC_OUTPUT
etc. This is mentioned clearly in the EMBEDDING section of the manual under
"AUTOCONF SUPPORT".
> - having the ability to prefix all public symbols with an arbitrary
> string, preferably via an argument to the configure M4 macro
All public symbols are already prefixed with ev_ and there are no public
symbols except as required by the API. If you need to rename some symbols
it is easy enough to do so yourself with a simple #define.
> - having one or both of the following:
> - having the libev library not be installed, but rather be
> treated as a convenience libtool library (so that it can be sucked up
> into a larger, upper-level library), and/or
Thats up to you when embedding, as libev is just sourcecode when you
embed it and no Makefile etc. Autoconf support is fully optional even,
as libev is fully configurable without it (see section "PREPROCESSOR
SYMBOLS/MACROS" in the "EMBEDDING" section of the manual).
> - having the ability to prefix the name lib the libev library,
> preferably via an argument to the configure M4 macros
I don't understand what "prefix the namelib the libev library" means, but
thats also up to you, when embedding, you can distribute sources as you
fit (see "FILESETS" in the "EMBEDDING" section...).
> These kinds of things are necessary to be able to have a fixed version
> of libev embedded in a software package while not interfering or
> creating ambiguities with a libev that is already installed on a
> target system.
Hmm, no: The ability to rename symbols is certainly not required to avoid
conflicts with system-install libraries unless your embedding approach,
sourcecode or makefile etc,. is buggy (in which case renaming of symbols
will be of little help to you!).
In any case, it seems you completely ignored the documentation, and didn't
even look at the sources: libev is fully embeddable ever since it was
created, and this is fully documented ever since documentation for it
exists, as you can see from the many examples of software packages that
embed libev, such as gvpe, rxvt-unicode or the EV perl module (all of
which, again is mentioned under the "EMBEDDING" section in the manual).
Please give a look at the existing documentation and code first, I spent
a lot of time and effort to write the documentation and make libev
embeddable, and the minimum thing you can do is first read it and then
tell me what needs to be improved with the documentation (or the code) so it
becomes suitable.
There is also considerable embedding experience available in the wild, so
it is unlikely that something essential is missing.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
