Re: module cleanup [1/n]

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

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