-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Gary V. Vaughan on 9/11/2007 3:44 PM: >> This adds a refcount builtin to the load module. I still think it is a >> bit odd that importing helper symbols from an m4 library affects the >> symbol table, but didn't see an easy way to fix it as part of this patch. > > I'm not sure I understand you. Could you explain what you mean by > 'helper symbol', > and what 'symbol table' you are referring to?
libgnu's esyscmd does M4_MODULE_IMPORT (m4, m4_set_sysval); in other words, it needs the m4_set_sysval entry point in libm4. But in the process of importing that entry point, it currently ALSO had the side effect of re-loading all of libm4's builtins into the m4 symbol table. > >> $ m4 -m load >> refcount(`m4') >> 1 >> unload(`m4')refcount(`m4') dnl no longer in table >> 0 dnl no longer in table >> >> esyscmd(`echo') >> >> >> refcount(`m4') dnl esyscmd imports from m4 module, reloading macros >> 1 And that was an example of what I found confusing. I think that once the user does unload(`m4'), dnl should not be available until the user does load(`m4'), even if, in the meantime, they use esyscmd which happens to rely on entry points available in libm4. In other words, the libltdl reference count of libm4 will be one, but the module load count (either via the refcount builtin that is in CVS right now, or if I rewrite that as suggested to make the m4modules builtin more powerful, then the number of times that `m4' appears in the m4modules output) is zero. > > I see no reason to add another arbitrary builtin, where m4modules itself > can > easily be extended to provide sufficient functionality. Let's revert > this, and > instead have m4modules list the stack of loaded modules. OK, I'll work on that next. It may be another couple days before I post my 4/n patch. > > If we were to keep the refcount builting, libltdl tracks it for us, so > there is > no need to duplicate that code again. The libltdl refcount is retrieved > with: > > lt_dlgetinfo(module->handle)->ref_count Indeed, the lt refcount is what we were using prior to my patch. However, as pointed out above, I don't think it is the right count to use. On the other hand, if I make m4modules track load/unload pairs reliably (something which libltdl does not do, since it flattens multiply-loaded modules into a single position in its traversal), then I could use the m4modules implementation to track refcount rather than having a refcount member in m4_module. I'll play with this idea while preparing the patch. - -- 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 iD8DBQFG6TFb84KuGfSFAYARAmM/AJ4mUWiVedm44nxqsPnQMvbhJgoj4QCfSJ3n GfVrXxUPKW5pcGlh3mhOLRQ= =VMzt -----END PGP SIGNATURE----- _______________________________________________ M4-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/m4-patches
