Re: repos

[stephan b. <st...@s1...>]

On Saturday 02 October 2004 14:33, martin f krafft wrote:
>   libdllfinder++ (or maybe libsofinder++)
>   libmodloader++
>
> The first exports an API to search the filesystem for a DLL that
> exports certain functionality. 

You're quickly getting into the realm of DLL-based symbol lookups 
(dlsym()), which are error prone and not type-safe.

> It should be able to take a class 
> name (which we can translate to the class constructor and search for
> the function), and it should be able to use
>
>   - a config file specifying paths
>   - an environment variable of paths
>   - a path list in the function invocation

cllite provides all but the first. It could trivially provide the first 
using s11n, but that would introduce a cyclic dependency between the 
two. Thus... cllite could do the first with some custom config file 
code.


> to search. The return value should be the absolute filesystem path
> of the DLL defining the class, or it throws an exception otherwise.

What's the use of a search path if you're gonna require absolute file 
paths? Two problems:

a) You've got to allow for search paths, (as you said above).

b) Requiring the ".dll" or ".so" extension to be provided by the client 
means the client has to know what platform he's on. In my experience 
moving this into an #ifdef block in the dll loader is much more 
convenient for the client.

Allowing the client to pass a base name is, IMO, an ideal solution for 
DLL lookups, for several reasons. First, let's look at a typical 
client-side call:

	open_dll( "foo"[, "optional:PATH:list"]" );

That would find, depending on the platform:

.\foo
./foo
.\foo.dll
./foo.so
c:\windows\system32\foo
c:\windows\system32\foo.dll
/usr/lib/foo
/usr/lib/foo.so
/usr/local/lib/foo
/usr/local/lib/foo.so

(i'm going off of cllite's behaviour here.)

The reason that ./foo would match is simple: if the client passes 
"foo.so", we want that to match. For that to happen, we have to allow 
for the case that the user has provided a full filename, and does not 
rely on the automatic extension lookup. i will agree that this 
behaviour is arguable, and that it could/should be made policyable. In 
practice it's never failed me, but i will admit that the possibility of 
error is there, e.g., when ./foo or /usr/lib/foo is a directory, a 
binary, or some other type of file.

For the implementation of the class which does these lookups, see  
path_finder.?pp in the class_loader source tree. It supports a list of 
extensions, like a search path: ".so:.SO:.mylib:.whatever"


> First, we must check if (a) such work already exists, and (b)
> whether it is possible at all. Remember that mangling it a bitch,
> but you probably know this much better than I do.

Amen, brother. We won't dwell on that point. :) Brrrrr....

> The second library then merely loads the DLL at runtime, registers
> the class with libfactory++ and makes the user happy. It can either
> just use the class name to identify the builder in the registry or
> generate a unique name on the fly. I guess both should be possible,
> and with the latter, it should be possible to use other types for
> the index than std::string.
>
> What do you think?

i think you're right on track, except that i'm still fuzzy on the line 
between module loader and dll loader. i haven't yet grasped the 
conceptual difference between the two: they seem to be the same (or 
very, very similar) to me. Can you clear that up for me?

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts