Petr Machata <[email protected]> писал в своём письме Thu, 12 Mar 2015
00:25:36 +0300:
Also, you don't want to simply call read_config_file recursively, as
that would re-read the file every time it's included. You also still
want to allow the full suite of overrides that ltrace admits,
i.e. looking through XDG_CONFIG_DIRS et.al.
I don't think I do, actually! If we do that, then the includer is never
going to know what
it's including. I.e., if a.conf includes b.conf, and b.conf is overridden,
then the override
might not contain the stuff that a.conf depends on, so it'll be broken. I
think we should only
search in a.conf's directory in this case.
The right way about it is to go through protolib cache, which handles
all this stuff. So read_config_file would need to get an argument of
the type struct protolib_cache *. An include line would trigger a call
to protolib_cache_load. The result would be added to the currently
loaded protolib by protolib_add_import.
Hmm... I don't really want to include complete protolibs into other
protolibs, though. Okay, for libc.so.conf and libpthread.so.conf I do, but
that's an exception, not the rule. For the general case, I envision a
C-like structure, where there are "header files" with common type
definitions, but which aren't necessarily complete protolibs themselves.
Like this:
types.inc:
typedef ldouble = double;
libc.so.conf:
include "types.inc";
ldouble strtold(string, +string*);
; some of libpthread's symbols are duplicated in libc
include "libpthread.so.conf"
lib.so.conf:
include "types.inc";
ldouble sinl(ldouble);
Now, I suppose, we could require the header files to be valid config files
in themselves (types.inc is), and then we could store them as protolibs in
the cache, but honestly, I don't see much point in that. They're going to
be parsed at most once per library, which I don't think is a big deal, and
if we do cache them, they'll just stay in the cache after all the library
configs have been parsed, serving no purpose.
Thoughts?
_______________________________________________
Ltrace-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
