-----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-----
_______________________________________________
M4-discuss mailing list
M4-discuss@gnu.org
http://lists.gnu.org/mailman/listinfo/m4-discuss
