Re: m4 module loader interface simplifications

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Gary V. Vaughan on 2/17/2008 3:46 AM:
| I think we should abstract away the difference between {s,}include of an
| m4 file and of a dso, and do away with load/unload altogether.  It's
| perfectly possible to keep track of which builtins are still attached to
| m4 macros, and to unload a module again once it no longer provides any
| code that can still be accessed... but, even that I think is
| unnecessary.

Interesting idea.  But can it be error-proof?  In other words, if you use
include(`foo.m4'), how do we distinguish between text files with macros
and binary files with dynamic module content?  Suppose the user has
M4PATH=dir1:dir2, where dir1/foo is text and dir2/foo.so is a shared
module - if you try the libtool interface for loading 'foo' first, then
foo.so will be loaded rather than dir1/foo.

|  After all, why would someone load  a module in the first
| place if they don't want to use the code it provides?

If m4 is used in a long-running process, then unloading unneeded dso's
provides better memory usage.  But I don't if m4 will ever be quite as
dynamic as something like apache, so blindly leaving stuff loaded probably
isn't an issue for m4.

| This in turn opens the possibility of mixed dso/m4 modules.  Such a
| module would be a directory named after the module containing m4 files,
| one of which should have a predictable name (__init__.m4{,f} a la
| python?  or an m4 file with the same name as the containing directory?)
| that
| runs when the module is loaded, and can pull in code from other files in
| that module.

So you're proposing the extension of include(`dir') being equivalent to
include(`dir/file'), where file is either a predictably named text file or
predictably named dso?  At which point, you name `dir' according to the
module it is providing?  Seems reasonable.  It would be interesting to see
code along these lines, to help decide how maintainable this approach
would be.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             [email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFHubqq84KuGfSFAYARAkHDAJ9SMy5mkQegwqGbR7I6sTOaU2NF9QCYw8Ei
jwE15ImB1pf3KvFQA8wetA==
=fAXj
-----END PGP SIGNATURE-----