vm team mailing list archive

[Tim Cross <tcross@xxxxxxxxxxxxxxx>]

From: Uday S Reddy <u.s.reddy@xxxxxxxxxxxxx>
Subject: Re: [Vm] compilation warnings
Date: Sat, 3 Jul 2010 10:40:33 +0100

> Hi Tim,  Thanks for looking at the warnings.
> 
>> Can I have some clarity on exactly what level of bacwards version
>> compatibility we want? 
> 
> I think we have been through this before, and I added a note to the
> README file about the version compatibility that we have in effect for
> the 8.2.x releases.  
> 
> I defer to Ulrich on deciding version compatibility issues.
>

Sorry, I forgot that. I'm missing my 'archives' of old messages at the moment
while I wait to get my main system fixed. 
 
>> I think this is relevant because it can impact on how
>> we 'fix' some of the warnings. For example, if the warning is for something
>> that is now obsolete in versions we support, we can just remove it or change
>> it to whatever it should now be. However, if it is something that is still
>> part of a version we want to support, then we probably need to put some
>> version branching, i.e. use eval-and-compile etc. 
> 
> What I normally do is to create a "vm-" version of the primitive where
> version-based branching is contained.  See the revision 836 and its
> internal revisions, especially the primitives added to vm-misc.el, for
> how we do this.
> 
>> Secondly, if we do need to put version dependent code in, can we assume VM is
>> always run as a compiled binary i.e. can use eval-when-compile rather than
>> eval-and-compile or would it be preferrable to just use eval-and-compile? We
>> currently have both in the code. For this situation, I would tend to go with
>> eval-and-compile as it is sometimes useful when debugging/developing to run
>> interpreted and not byte compiled code. 
> 
> I don't think we can assume that VM is run as a compiled binary.  Some
> users prefer to use it uncompiled.  Plus, we use it uncompiled during
> the development itself, to enable tracing and all that.
>

Yes, that was my feeling as well, just wanted to check rather than assume.
Note however, I did notice that some files use 'cl and I think some other
packages only at compile time i.e. using eval-when-compile. Not sure how this
would affect results when running uncompiled. 
 
>> Is using these two macros the correct way to handle version dependent code?
> 
> We would like to avoid version-dependent binaries if at all possible,
> because it is a pain to maintain multiple binaries.  If something is
> really needed at comiple-time for performance, then yes, but otherwise
> it is best to postpone the checks to run-time.
>

I notice some 'obfuscated' code that was introduced to avoid warning messages
for emacs 19. It would probably be good to clean some of that up and make it
less obfuscated at some point in the future. 
 
>> PPPS. I find this encoding stuff complex and confusing and really
>> don't understand it that well, though I've been lazy and an arrogant
>> english speaker!
> 
> Fortunately, we have Ulrich who knows this stuff well.
> 

That is good. I think we have a bit of stuff in there that is not necessary
given changes in Emacs - for example, MULE as a separate package is no longer
required with current emacs versions and it appears the handling of different
encodings is much more straight-forward and reliable than it previously was.
There looks to be a bit that could be simplified/clarified, though sorting it
out is non-trivial. 

Tim

P.S. I forgot to mention in my message regarding the fixes I have done that I
commented out a couple of defvar definitions for standard emacs variables. I
suspect they were added at some point to stop compiler warnings. However,
commenting them out has made no difference. They are in vm-mime.el. If they
are needed for emacs 22.1, we should just make it explicit they are only
needed for that version as this will make it clear why they are there and when
they will no longer be needed (i.e. when we eventually stop support for emacs
22). I think it is always a good idea to keep an eye towards future
maintenance and try to make things as explicit as we can.