From: mathog@seqaxp.bio.caltech.edu
Sent: Thursday, July 13, 2000 5:34 PM
To: Info-VAX@Mvb.Saic.Com
Subject: Re: Porting assistance for GNU code (GnuGP)

In article <009ED05E.4CE7D5D3@SendSpamHere.ORG>, system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) writes:
>I've been toiling with some GNU code on and off for a few months and I
>am thoroughly convinced that the GNU crowd is completely insane.  Most 
>of the problem is not the C code itself but the insanity of the build
>environment.  C preprocessor hacks to build intermediate makefiles that
>build more makefiles via C preprocessor hacks...  ugly, fugly, GNUgly!
>Another insanity is the way many of the GNU packages check to see if a
>C library functions exist so that psycho-conditional code can be used
>to incorporate fucntions the environment may or may not possess.

Amen.  To that.  But "autoconf" (hawk, spit) is all the rage in Unixdom.
The DII-COE better bring along autoconf based builds or it's a complete
joke if real Unix compatibility is a goal. 

>
>Anyhow, good luck to you.  If you decide to tackle the project get a
>couple of bottles of strong headache medicine and a well-padded head
>protector (to safeguard against any permanent bodily harm you may in-
>flict upon yourself whilst banging your head against the wall!) and 
>have a go at it.

Nah.  Don't beat your head on the wall - do it the easy way.

Go to a Unix box, unpack, cd into the directory.

% ./configure
% make -n > make_vms.com

Copy make_vms.com back to your VMS machine.  Open it in NEDIT or some other 
editor which allows very wide lines.  There will be two classes of CC lines 
(if you're lucky, an infinite number if you're not.)  One will correspond 
to the compiles and the others to the links.  Copy one of the compile lines
up to the top and edit it from:

cc -I. -Ifoo -DBLAT -DSPLAT -O

to

$ mycc :== cc/standard=ansi89/prefix=all/include=([],[.foo])/define=(BLAT,SPLAT)/warn=enable=all

Yes, that's very optimistic, odds are it isn't ANSI compatible code, but 
YOU want YOUR code to compile cleanly this way.

then do a global replace of the unixy cc line with

$ mycc 

You'll probably also have to move around or remove the "-o out.o" bits.

Then do the same sort of thing for the LINK "cc's", where you define a 
MYLINK symbol at the top of the procedure, and global replace it all the 
way down.

Change all lists like:

 foo.o moo.o goo.o

to 

 foo.obj, moo.obj, goo.obj

Are there "ar" statements?  In those locations you probably want to put in

 $ create/object/library somename.olb  foo.obj, moo.obj, etc.

If the package builds more than one executable and does NOT have "ar" 
statements you may still want to build object libraries.  It will reduce
your link statements from a huge list to just

 $ mylink/exe=foo.exe foo.obj,biglib.olb/lib

Change other statements like:

  mv foo.o bloo.o               replace mv with RENAME
  cp foo.o bloo.o               replace cp with COPY
  sed,awk,perl,sh               hunt down the author and beat them senseless

Then comes the fun part - actually getting the code to build.  If it's well 
written code (which I do occasionally see) it will build cleanly at this 
point.  More likely it will generate several thousand error messages.  DO 
NOT back off on the compiler stringency - take the time and fix all the 
moronic bugs you find and send the lengthy list back to the author/
maintainer.

Got a clean compile?  DO NOT try to run it yet.

First search the code for "/", system(), fork(), ioctl() (if it does 
terminal manipulation) and select() (if it's X11 code).  Code in those 
regions is unlikely to function properly.

Now try and run it. 

When it blows up, and it will, go back and build a DEBUG version and 
uncover the numerous bugs which never expressed fatally on any Unix.
(Especially useful, if the code uses free() put in

#define free myfree

and have myfree contain a call to decc$free() and check the status.  That 
way you can trap many memory errors.)

Simple eh?

( Pray that this package does not contain C++ code!)

If the DII-COE can get packages like this to run on OpenVMS, without having
to put in all this work, then maybe, just maybe, there might be a _real_
OpenVMS renaissance. 

Regards,

David Mathog
mathog@seqaxp.bio.caltech.edu
Manager, sequence analysis facility, biology division, Caltech 
**************************************************************************
*                                RIP VMS                                 *
**************************************************************************