🚀 go-pugleaf

>>>>> 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 ??

>> > After downloading the sources, the first step is to modify the
>> > Makefile.  I'd suggest moving the SHELL definition above the user
>> > configurable line as sometimes the shell that people want to use
>> > (even on UNIX systems) is not /bin/sh.

> If you're building someplace that doesn't have /bin/sh, you
> should be worrying about a lot more than editing below the "no
> user servicable parts" line.  If /bin/sh is available, then
> that's what should be used.  Otherwise, you're really on your
> own.

While there are things that might break on (say) a Windows system
other than the SHELL, I was only thinking of SHELL interfaces and UNIX
systems.  However, I understand your point and am not wed to mine.

>> > 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.

The ".exe" issue would apply in a Cygwin environment, but it's your
choice to support that or not.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA