[COMMIT] Eliminate some non-X11 build failures

[Stephen J. Turnbull]

IMO, as soon as you accept responsiblity you should list yourself, so that
reviewers know they need to check with you before approving patches to
that package.  You can set a policy that they can commit anything they like,
of course, but it's *your* package, you are the boss.  There are checks and
balances (Norbert can approve patches as "package czar", and security risks
or code that tickles crashes in versions still in use can be approved by any
reviewer), but the basic idea is that we stay out of your way until
you invite us
in.

On 10/13/07, mike.kupfer at xemacs.org <mike.kupfer at xemacs.org> wrote:
> QUERY
>
> >       * mh-utils.el (mh-funcall-if-exists):
> >       If a function is bound at compile time, that has a limited amount
> >       to do with whether it's bound at runtime. Don't trust the check at
> >       compile time, use the runtime check instead.
>
> In MH-E 8 (which I am slowly... very slowly :-( ... getting ready for
> the package build), mh-funcall-if-exists looks like
>
>   (when (fboundp function)
>     `(when (fboundp ',function)
>        (funcall ',function , at args))))
>
> That is, if the function isn't bound at compile time, don't bother
> checking at runtime.  Is that going to be a problem?
>
> Also, will I need to do a test-build with a non-X11 XEmacs before
> committing?
>
> And one organizational question: I was holding off on listing myself as
> the MH-E maintainer until I got the MH-E 8 update in shape.  Maybe I
> ought to list myself now?
>
> thanks,
> mike
>
> _______________________________________________
> XEmacs-Beta mailing list
> XEmacs-Beta at xemacs.org
> http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
>