🚀 go-pugleaf

David Masterson  <David.Masterson@synopsys.com> wrote:
 > >>>>> Kyle Jones writes:
 > 
 > > David Masterson  <David.Masterson@synopsys.com> wrote:
 > 
 > >> > I found that bbdb-insinuate-vm (BBDB 2.32) expects to find
 > >> > vm-autoloads, so I had to download the sources to VM after all.
 > >> > You might want to let the BBDB people know if there is a better
 > >> > way of loading (and insinuating into) VM.
 > 
 > > I have no idea what actions BBDB presently takes, so I couldn't
 > > help them without further guidance.
 > 
 > It appears that bbdb-vm.el does a 'require' on vm-autoloads (as well
 > as 'load-library' on other parts of VM).  Since you're also
 > distributing VM as one ".el?" file, that suggested (to me, at least)
 > that for other packages to require vm-autoloads is the wrong approach
 > on their part for loading up VM.  Unless, when you build a single file
 > "vm.el?", you include all the 'provide's ??

I recommend (require 'vm).  In the case of the autoloading build,
(require 'vm) will pick up the autoloads file.  In the case of
the non-autoloading build it will pick up everything.  But since
I changed a lot of VM's defmacro calls to defsubst, requires
might not be necessary to build BBDB.  I don't know for sure; the
maintainer of BBDB should check that.

 > >> > I'd also suggest putting in a commented out setting for CC and
 > >> > CFLAGS above the user configurable line so that people know they
 > >> > *may* need to modify it.  I'd also put into the Makefile an EXE
 > >> > macro that will be defined to "" on UNIX and ".exe" on Windows.
 > >> > With that you could change the definition of the UTILS to include
 > >> > the EXE macro as in "qp-decode$(EXE)" (also any appropriate
 > >> > Makefile targets).  [...]
 > 
 > > This is more than I am willing to do to support Windows.  This is a
 > > point of principle and self-interest more than of labor.  Inasmuch
 > > as Microsoft is trying to destroy the open source community and the
 > > open standards upon which I base my livelihood, it isn't in my
 > > self-interest to invest much time in making it easier to use their
 > > products.
 > 
 > Well, my first sentence still applies.  CC, in particular, is very
 > often *NOT* /usr/bin/cc on UNIX systems (for instance, 'xlc' on AIX).
 > CFLAGS also may need modification based upon the C compiler used.

Hmm.  OK.