Subject: Python for OpenVMS Build Environment

I set up the build environment in three directory trees.

The first directory tree is created by unpacking the UNIX source.  I use
ODS-2 filename conventions, even though I am building on an ODS-5
volume.  This is so that I can mirror it on one of my VAX systems for a
VAX version.  This directory tree is read-only to the build and testing
account.

In this case, the UNIX source directory tree starts with
PROJECT_ROOT:[PYTHON]


The next directory is a set of CMS libraries that are used to contain
the files that are changed for the port.  The CMS library tree contains
a reference directory for the modules actually being used.

This directory tree starts with CMS_ROOT:[PYTHON_VMS].

And finally the work directory is PROJECT_ROOT:[PYTHON_VMS].

A file SETUP_PYTHON_BUILD.COM is used to set up logical names as a
search list for the directories to be used in the build procedure.

These logicals are put in the job table to speed up the build.
MMS and MAKE uses spawned processes, and the job table is common to
both.  The process logical name table is copied with the spawn, so a lot
of logical names will slow things down.

This will usually require increasing the JTQUOTA account quota.

The logical names, listed toward the end of this document indicate the
build environment.

The LCL_* logical names reference the work directory only.

The REF_* logical names reference first ths CMS directory, and then the
UNIX source directory of the project being ported.  These should be
considered read-only.

And the PRJ_* logical names reference the work directory, followed by
the REF_* logical name for the above path.

The file PYTHON.MMS was created by hand editing the information that the
  PYCONFIGURE script would have used to create the makefile as close as
I can do this.  I try to keep the same build targets as in the original
as much as practical.  If I can not implement a function, I will make
the target just print that out.

The Python.mms script is supplemented with command files and TPU macros
to do things that a makefile can, but MMS can not.

I will be posting the files in separate topics in this newsgroup.


Now one of the items to be covered is an approximation of the CONFIGURE.
script that is run on UNIX systems.

These configure scripts are less portable than the programs that they
are configuring.  They require maintenance by someone for every platform
  that is supported, so for a software maintainer, there is not much
auto about autoconfigure.

The configure script produces two things, the makefile, which does not
change much from release to release, and the config.h file which may
change a lot.

In the case of PYTHON, instead of CONFIG.H, the file is called PYCONFIG.H.

I am using the FRONTPORT library from the OpenVMS 5.0 Freeware CD-ROM
set to supplement the C RTL.  This may not be needed.

I create the PYCONFIG.H file by running the command file PYCONFIG_H.COM.
  It can also be invoked from the PYTHON.MMS file.

PYCONFIG_H.COM can read the the configure.in, and the pyconfig.h.in
files, and then generate most of the pyconfig.h.  It pretty much knows
how to search the DECC$SHR image and the DECC$RTLDEF.TLB for symbols.
It also knows how to search the Frontport library for symbols.

PYCONFIG_H.COM does not yet know how to search the GNV shared images for
symbols.

Now as I post these files, keep in mind that it is a work in progress,
and not complete or working.  I had the 2.2x port running further than I
have the 2.3a port.


Now the PYCONFIG_H.COM does not get everything needed, and currently is
getting a few thing wrong as the compiler header files are slightly
ahead of the DECC$SHR image.

So what the resulting PYCONFIG.H that is generated has is a #include of
PYCONFIG_VMS.H that is manually edited to make up the difference.


Now I try not to have any #ifdef __VMS present in the ported code.  I
will first try one of: A macro in PYCONFIG_VMS.H, adding a missing UNIX
routine to FRONTPORT, or using a TPU routine to do an edit to the UNIX
module.  If none of those are practical, I will create a VMS specific
module to do the function.  Using Operating specific source modules is
already practice in PYTHON.


Now I have a special hack that is in the PYTHON.MMS file.  The C
compiler command is:

CINC=/include=(PRJ_SRC:,$(PYINC),FRONTPORT__DIR:)
CDEFX= MOD_'f$element(0,"-",f$parse("$*",,,"NAME"))', HAVE_CONFIG_H
CDEF = /define=($(CDEFX))
CDEF1 =
/define=($(CDEFX),BUILDNO='f$parse("lcl_src:buildno.tmp",,,"VERSION")'

What the "MOD_'f$element(0,"-",f$parse("$*",,,"NAME"))'" does is creates
a definition with the Module name visible to the compiler.

So for FOO.C, there is effectively a #define MOD_FOO being done.

So now in the PYCONFIG_VMS.H, I can put in definitions that are local to
a module.  So if for module FOO.C, I need to have to replace a call to
xyzzy() with a special version vms_xyzzy(), but have all the other
modules still call xyzzy(), I can do that.

Below is directory of the modules I currently have in the work
directory, and I do not know that all of them are currently in the
build.  I currently have no modules in the cms_root:[python_vms]
directory.  As I post these, I will be checking them into the CMS library.

I probably do will not have time to post all of these tonight, and will
try to get the rest tomorrow night.

I will try not to be posting any files that I determine that the build
procedure generates.

The directory listing is below.

-John
wb8tyw@qsl.network
Personal Opinion Only

EAGLE> dir [...]*.*;/exc=(*.obj,*.exe,*.olb,*.stb,*.log,*.dir)

Directory PROJECT_ROOT:[PYTHON_VMS]

BUILD_CONFIG_INCLUDE_FILES.COM;15
CONFIG_H.COM;182    FRONTPORT.H;58      LIBPYTHON_AXP.OPT;3
LIBPYTHON_AXP.OPT_SRC;2                 PYCONFIG.H;1
PYCONFIG_H.COM;4    PYCONFIG_VMS.H;56   PYTHON.MMS;176
PYTHON.OPT;3        PYTHON.OPT_SRC;2    python_vms_modules.mms;6
PY_IDENT.OPT;3      SETUP_PYTHON_BUILD.COM;1
set_python_ident.com;29
UNIX_C_TO_VMS_C.TPU;245

Total of 18 files.

Directory PROJECT_ROOT:[PYTHON_VMS.INCLUDE]

graminit.h;3

Total of 1 file.

Directory PROJECT_ROOT:[PYTHON_VMS.MODULES]

CONFIG.C;1          config.tpu;2        getbuildinfo.c;1
main.c;2            VMS_CONFIG_EXTERN.H;1
VMS_CONFIG_STATIC_INIT.H;1              vms_getpath.c;12

Total of 7 files.

Directory PROJECT_ROOT:[PYTHON_VMS.PYTHON]

DYNLOAD_SHLIB.C;1   graminit.c;3



Logical names used in the build:

(LNM$JOB_81712F40)

   "PRJ_DEMO" = "LCL_DEMO:"
         = "REF_DEMO:"
   "PRJ_DEMO_EMBED" = "LCL_DEMO_EMBED:"
         = "REF_DEMO_EMBED:"
   "PRJ_DEMO_PYSVR" = "LCL_DEMO_PYSVR:"
         = "REF_DEMO_PYSVR:"
   "PRJ_DEMO_SGI" = "LCL_DEMO_SGI:"
         = "REF_DEMO_SGI:"
   "PRJ_DEMO_SGI_VIDEO" = "LCL_DEMO_SGI_VIDEO:"
         = "REF_DEMO_SGI_VIDEO:"
   "PRJ_DOC" = "LCL_DOC:"
         = "REF_DOC:"
   "PRJ_DOC_EXT" = "LCL_DOC_EXT:"
         = "REF_DOC_EXT:"
   "PRJ_DOC_HTML" = "LCL_DOC_HTML:"
         = "REF_DOC_HTML:"
   "PRJ_DOC_INFO" = "LCL_DOC_INFO:"
         = "REF_DOC_INFO:"
   "PRJ_DOC_TOOLS" = "LCL_DOC_TOOLS:"
         = "REF_DOC_TOOLS:"
   "PRJ_DOC_TOOLS_SGMLCONV" = "LCL_DOC_TOOLS_SGMLCONV:"
         = "REF_DOC_TOOLS_SGMLCONV:"
   "PRJ_GRAMMAR" = "LCL_GRAMMAR:"
         = "REF_GRAMMAR:"
   "PRJ_INCLUDE" = "LCL_INCLUDE:"
         = "REF_INCLUDE:"
   "PRJ_LIB" = "LCL_LIB:"
         = "REF_LIB:"
   "PRJ_LIB_TEST" = "LCL_LIB_TEST:"
         = "REF_LIB_TEST:"
   "PRJ_MISC" = "LCL_MISC:"
         = "REF_MISC:"
   "PRJ_MODULES" = "LCL_MODULES:"
         = "REF_MODULES:"
   "PRJ_OBJECTS" = "LCL_OBJECTS:"
         = "REF_OBJECTS:"
   "PRJ_PARSER" = "LCL_PARSER:"
         = "REF_PARSER:"
   "PRJ_PYTHON" = "LCL_PYTHON:"
         = "REF_PYTHON:"
   "PRJ_RISCOS" = "LCL_RISCOS:"
         = "REF_RISCOS:"
   "PRJ_RISCOS_MODULES" = "LCL_RISCOS_MODULES:"
         = "REF_RISCOS_MODULES:"
   "PRJ_RISCOS_PYTHON" = "LCL_RISCOS_PYTHON:"
         = "REF_RISCOS_PYTHON:"
   "PRJ_SRC" = "LCL_SRC:"
         = "REF_SRC:"