Re: module cleanup [1/n]

Gary V. Vaughan Fri, 14 Sep 2007 02:44:06 -0700

Hi Eric,

On Sep 13, 2007, at 1:25 PM, Eric Blake wrote:

thanks for the review


My pleasure... you're doing the hard work though! :-D

According to Gary V. Vaughan on 9/11/2007 1:42 PM:

Perhaps we could add an options parameter to load() like this?

   load(`nosuchmodule', `nocomplain')


I'm thinking more like:

load(`nosuch') == load(`nosuch', `fatal') => die immediately

load(`nosuch', `error') => issue a warning to stderr, affect exit status,

but proceed (unless -EE specified on command line)

load(`nosuch', `warn') => issue a warning to stderr, leave exit status
alone (unless -E specified on command line)

load(`nosuch', `silent') == load(`nosuch', `quiet') => like sinclude -
proceed without warning and without affecting exit status


Looks good.  Maybe similar extensions for include would be good too?

It certainly can't do any harm to be more careful about this.  HEAD
libltdl does
assume that only one module loading extension point will be responsible
for loading
of any module. That is, if a module is written to be loaded by the m4
module loader,
then it shouldn't be loaded by a different module system (say the
libsnprintfv
extension point -- if we reimplemented m4's format builtin using
libsnprintfv).
Really? I thought the whole point of adding the lt_dlinterface_id was to
allow multiple loaders.  Anyways, more on this in response to 3/n.


You're right.  What I meant was that this very system won't work if a
module is written to meet two interfaces, because both libsnprintfv and
libm4 could potentially load the same code through two different
extension points.  When I wrote all the interface checking code it

seemed like something no-one would want to do anyway, hence the assumption

that no-one would try to do so...

I'm loathe to keep adding builtins where we can extend existing builtins
to get
the same functionality in a clean intuitive way. m4modules is not yet
bound to
provide backwards compatibility, so we could simply have it add newly
loaded modules
to the list each time they are successfully loaded.  Membership tests
would be
unaffected, and a macro to count occurences could easily work out the
refcount of
a named module.
True. But the current m4modules implementation is quite dependent on the
libltdl traversal algorithm (currently stack-based, but lists multiply
loaded modules only once and in the order they were first loaded).
Changing m4modules to list every load of every module seems nicer than
having a new 'refcount' builtin, so I can revert that part of the patch,
but it means m4modules will now have to maintain an explicit list of
module loads, rather than relying on libltdl's list.


Okay.  We might try to keep any glue code that works around deficiencies
in libltdl isolated, so that after the next libtool release we can
improve libltdl and throw away the glue in m4.

Cheers,
        Gary
--
  ())_.              Email me: [EMAIL PROTECTED]
  ( '/           Read my blog: http://blog.azazil.net
  / )=         ...and my book: http://sources.redhat.com/autobook
`(_~)_      Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912

PGP.sig
Description: This is a digitally signed message part

_______________________________________________
M4-patches mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/m4-patches

Re: module cleanup [1/n]

Reply via email to