Richard Levitte wrote:
> Anyhow, life went on, and I simply didn't get the time to take up
> autoconf and concentrate on it, the rest followed by implication.
>
> So, why am I writing this? Well, I recently got reasons to start mucking
> around seriously with emacs again, perhaps with a slightly different
> approach. Also, I've heard some rumour that there's something that works
> very much like autoconf, except that it generates perl code instead of
> sh. Does anyone here know anything about this, or is it just an urban
> legend that has hit me and that I'd have to wait endlessly for?
As far as I know the only things that generate perl code are the IDE
things like perlbuilder (see http://www.perlbuilder.com/ ) or SWIG
(see http://www.swig.org/ ), although one might say that a2p, s2p, c2ph,
and h2xs "generate" perl code they are really more properly classified as
translators (although I suppose that is what autoconf is too).
MakeMaker does config work including package handling, but it generates
Makefiles (primarily for perl packages) not shell scripts.
In order to generate perl's Bourne shelll Configure script a tool
called either 'dist' or 'metaconfig' "generates" it by stitching together
the dist units in the metaconfig distribution. I've not worked with
dist/metaconfig too much but assume that it does little more than catenate
the shell scriplets. As far as I know it does not have a meta syntax that
can be converted to DCL like autoconf's configure.in -> configure or
configure.in -> configure.com can do. The configure.com that comes with
perl for VMS nowadays was pieced together by hand taking the bits of the
Bourne shell Configure script that seemed appropriate and/or humourous
enough to run on VMS.
At one time I was considering using the port of autoconf to generate
perl's configure.com. But since the unix portion of perl's Configure
does not use autoconf there were no input files to work with and
it seemed too much of a stretch to get the whole thing working.
Having up to date (meaning primarily DECC compatible in my case) versions
of GNU things on VMS would be quite valuable.
> About giving VMS code back into mainstream emacs, well, that has been
> attempted, a real long time ago when emacs 19 wasn't yet publically
> available (we're talking 19.0 to 19.12 or something like that). I was
> working through someone at the FSF (don't recall his name right now), but
> apparently RMS did feel it could be properly tested by the GNU project
> and decided that it wasn't worth it, or something like that (I didn't get
> all the details, just that it lead to a quite heated discussion). This
> is very sad, but I can understand RMS' reasons. His goal is to create an
> operating system with all imaginable tools in it, anything else being of
> minor interest. VMS support falls into that "minor" part, I'm afraid.
At one time I'd heard that support for Apple things was to fall by the
wayside too although recently there have be rumours that support
for things like Mac OS X in the gcc distribution is being "reconsidered".
Perhaps that announcement was due at least in part to the "opening" of
Apple source code. It has been a long time since VMS was relabelled OpenVMS
but there is always hope for GNU on VMS I'd think (even if it means carrying
the burden of separate packages for a time).
> About the lists that I was maintaining for GNU stuff on VMS, they're
> still there. See http://vms.gnu.org/mailinglists.html. They just
> haven't (as you say) been used very much lately...
>
> And now, this is getting to the point where I wonder if this is the right
> list for this discussion.
Perhaps vmsperl is not quite the correct place. I have tried to Cc: this
to [EMAIL PROTECTED] and will see what happens. I am
not (yet) subscribed to that list and I may see a bounce for other reasons
(forte.com is a domain disappearing from the net these days and I have to
start posting from [EMAIL PROTECTED] for some lists).
Thanks for the reply Richard. I can certianly empathize with "too much
else to do". There remains more to discuss IMO: autoconf.exe, emacs, etc.
Peter Prymmer
