curl/packages/vms/curl_gnv_build_steps.txt

From File: curl_gnv_build_steps.txt

$Id$

 Copyright 2009, John Malmberg

 Permission to use, copy, modify, and/or distribute this software for any
 purpose with or without fee is hereby granted, provided that the above
 copyright notice and this permission notice appear in all copies.

 THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
 ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
 OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

Currently building Curl using GNV takes longer than building Curl via DCL.
The GNV procedure actually uses the same configure and makefiles that
Unix builds use.

Building CURL on OpenVMS using GNV requires GNV V2.1-2 or the updated
images that are available via anonymous FTP at encompasserve.org in the gnv
directory.  It also requires the GNV Bash 4.2.45 kit as an update from the
same location.

The HP C 7.x compiler was used for building the GNV version.

The source kits are provided in backup savesets inside of the PCSI install kit.

Backup save sets are currently the only distribution medium that I can be
sure is installed on a target VMS system that will correctly unpack files
with extended character sets in them.  You may need to adjust the ownership
of the restored files, since /Interchange/noconvert was not available at the
time that this document was written.

[gnv.common_src]curl_*_original_src.bck is the original source of the curl kit
as provided by the curl project.  [gnv.vms_src]curl-*_vms_src.bck, if present,
has the OpenVMS specific files that are used for building that are not yet in
the curl source kits for that release distributed http://curl.haxx.se

These backup savesets should be restored to different directory trees on
an ODS-5 volume(s) which are referenced by concealed rooted logical names.

SRC_ROOT: is for the source files common to all platforms.
VMS_ROOT: is for the source files that are specific to OpenVMS.
          Note, you should create the VMS_ROOT: directory tree even if it is
          initially empty.  This is where you should put edits if you are
          making changes.
LCL_ROOT: is manually created to have the same base and sub-directories as
          SRC_ROOT: and VMS_ROOT:

The logical name REF_ROOT: is defined to be a logical name that is a search
list for VMS_ROOT:,SRC_ROOT:

The logical name PRJ_ROOT: is defined to be a logical name that is a search
list for LCL_ROOT:,REF_ROOT:

For the make install process to work, it must have write access to the
directories referenced by the GNU: logical name.
In future releases of GNV, and with GNV Bash 4.2.45 installed, this name
should be GNV$GNU:

As directly updating those directories would probably be disruptive to other
users of the system and require elevated privilege, this can be handled by
creating a separate directory tree to install into which can be referenced
by the concealed rooted logical name new_gnu:.  A concealed logical name of
OLD_GNU: can be set up to reference the real GNV directory tree.

Then a local copy of the GNU/GNV$GNU logical names can be set up as a search
list such as NEW_GNU:,OLD_GNU:

The directory NEW_GNU:[usr] should be created.  The make install phase will
create all the other directories.

These files do not create the directories in the VMS_ROOT and LCL_ROOT
directory trees.  You can create them with commands similar to:

  $ create/dir lcl_root:[curl]/prot=w:re
  $ copy src_root:[curl...]*.dir -
    lcl_root:[curl...]/prot=(o:rwed,w:re)
  $ create/dir vms_root:[curl]/prot=w:re
  $ copy src_root:[curl...]*.dir -
    vms_root:[curl...]/prot=(o:rwed,w:re)

One of the ways with to protect the source from being modified is to have
the directories under src_root: owned by a user or resource where the build
username only has read access to it.


Note to builders:

GNV currently has a bug where configure scripts take a long time to run.
Some of the configure steps take a while to complete, and on a 600 Mhz
DS10 with IDE disks, taking an hour to run the CURL configure is normal.
The bug appears to be in the SED for GNV 2.1.3 and GNV 3.0.1 where it
is taking far longer than it should to do I/O.  In addition, there are
reports that the SED in GNV 3.0.1 is broken so the SED from GNV 2.1.3
should be used instead.

The following messages can be ignored and may get fixed in a future version
of GNV.  The GNV$*.OPT files are used to find the libraries as many have
different names on VMS than on Unix.  The Bash environment variable
GNV_CC_QUALIFIERS can override all other settings for the C Compiler.

? cc: No support for switch -warnprotos
? cc: Unrecognized file toomanyargs
? cc: Warning: library "ssl" not found
? cc: Warning: library "crypto" not found
? cc: Warning: library "gssapi" not found
? cc: Warning: library "z" not found
u unimplemented switch - ignored


With these search lists set up and the properly, curl can be built by
setting your default to PRJ_ROOT:[curl.packages.vms] where the * is
replaced by the actual version of curl, and then issuing the command:

  $ @build_gnv_curl.com.

This command procedure does the following:

  $ @setup_gnv_curl_build.com

  $ bash gnv_curl_configure.sh

  $ @clean_gnv_curl.com

  $ bash make_gnv_curl_install.sh

  $ @gnv_link_curl.com

  $ purge new_gnu:[*...]/log


To clean up after a build to start over, the following commands are used:

   $ bash
   bash$ export GNV_DISABLE_DCL_FALLBACK=1
   bash$ cd ../..
   bash$ make clean
   bash$ exit

Then run the @clean_gnv_curl.com.  Use the parameter "realclean" if you are
going to run the setup_gnv_curl_build.com and configure script again.

   $ @clean_gnv_curl.com realclean

If new public symbols have been added, adjust the file gnv_libcurl_symbols.opt
to have the new symbols.  If the symbols are longer than 32 characters,
then they will need to have the original be exact case CRC shortened and
an alias in upper case with CRC shortened, in addition to having an exact
case truncated alias and an uppercase truncated alias.

The *.EXE files are not moved to the new_gnu: directory.

After you are satisfied with the results of your build, you can move the
files from new_gnu: to old_gnu: at your convenience.

Building a PCSI kit for an archictecture takes the following steps after
making sure that you have a working build environment.

   1. Make sure that you have a staging directory that can be referenced
      by the path STAGE_ROOT:[KIT]

   2. Edit the file curl_release_note_start.txt or other text files to
      reflect any changes.

   3. Define the logical name GNV_PCSI_PRODUCER to indicate who is making
      the distribution.  For making updates to an existing open source
      kit you may need to keep the producer the same.

   4. Define the logical name GNV_PCSI_PRODUCER_FULL_NAME to be your full
      name or full name of your company.

   5. If you are producing an update kit, then define the logical name
      GNV_PCSI_PATCHLEVEL to the letter E followed by a number.  Do not
      use a patch level for kits built from the daily CVS snapshot.

   6. Edit the file PCSI_GNV_CURL_FILE_LIST.TXT if there are new files added
      to the kit.  These files should all be ODS-2 legal filenames and
      directories.

      A limitation of the PCSI kitting procedure is that when selecting files,
      it tends to ignore the directory structure and assumes that all files
      with the same name are the same file, so every file placed in the kit
      must have a unique name.  Then a procedure needs to be added to the kit
      to create an alias link on install and remove the link on remove.

      Since at this time curl does not need this alias procedure, the steps
      to automatically build it are not included here.

      While newer versions of PCSI can support ODS-5 filenames, not all verions
      of PCSI on systems that have ODS-5 filenames do.  So as a post install
      step, the PCSI kit built by these steps does a rename to the correct
      case as a post install step.

   7. Build the PCSI kit with @pcsi_product_gnv_curl.com

       The following message is normal:
          %PCSI-I-CANNOTVAL, cannot validate
            EAGLE$DQA0:[stage_root.][kit]JEM-AXPVMS-CURL-D0719-6-1.PCSI;1
          -PCSI-I-NOTSIGNED, product kit is not signed and therefore has
          no manifest file

       This will result in both compressed and uncompressed kits for the target
       platform.

Good Luck.