Building for more than one host architecture

[jba@aps.anl.gov (Janet B. Anderson)]

Another goal in in using epics on more than one host architecture which has 
not been previously mentioned in the tech-talk dialog is to have application
developers automatically have the correct paths set. Since the `arch` command
does not always exist or yield the proper epics architecture value, the
startup files used to properly define epics path and environement variables
described in Chapter 4: Getting Started and in Chapter 7: Site Manager Interface
in the "EPICS Source/Release Control" manual have to be modified.  Here are the
changes that we are currently thinking of proposing.

   All epics base and extension developers and epics application developers now
   execute a epics startup script when they login.  This startup script would
   be modified to define a new HOST_ARCH environment variable using the
   following statement
   
      setenv HOST_ARCH `/usr/local/epics/startup/HostArch`
   
   where HostArch is the file created by Nick Rees. (The master copy of the
   HostArch file would exist in the epics/base/tools directory.)

   This new environment variable would then be used as follows.

       1)  The EPICS startup script will add the following directories to
           a user's path (for application development)
           
               ./base/bin/$HOST_ARCH
               ./base/tools
               /usr/local/epics/extensions/bin/$HOST_ARCH
   
       2) Developers of base or of both base and extensions have the following
          lines in the epics/cshrc file in their development directories.
   
                DVL = `pwd`
                set path = ($DVL/base/tools $DVL/base/bin/$HOST_ARCH $oldpath)
                rehash
   
       3) Developers of extensions only have the following lines in the
          epics/cshrc file in their development directories.
   
                REL = <epics release>
                set path = ($REL/base/tools $REL/base/bin/$HOST_ARCH $oldpath)
                rehash

       4) HOST_ARCH could come from the environment for all builds of base and 
          extensions and for all builds in the application directories. Then the
          CONFIG_SITE file would probably have the following lines
   
               #  HOST_ARCH is now an environment variable
               ifndef HOST_ARCH
                     HOST_ARCH=unsupported
               endif

   

Also, how about making something like the following changes to the CONFIG files
to allow a site to optionally specify only a subset of their host architectures
to do cross compiling. 

        CONFIG_SITE
             CROSS_COMPILER_TARGET_ARCHS=mv167 ...
             CROSS_COMPILER_HOST_ARCHS=sun4 (cross compile only on sun4)
           or
             CROSS_COMPILER_HOST_ARCHS=  (cross compile on all host archs)

        CONFIG 
            Unconditionaly include CONFIG_COMMON file
            (i.e  move "ifdef T_A" down) 

        CONFIG_COMMON
             BUILD_ARCHS=$(HOST_ARCH)
             ifndef CROSS_COMPILER_HOST_ARCHS
                 BUILD_ARCHS+=$(CROSS_COMPILER_TARGET_ARCHS)
             else
                  ifeq ($(HOST_ARCH),$(findstring $(HOST_ARCH),$(CROSS_COMPILER_HOST_ARCHS)))
                      BUILD_ARCHS+=$(CROSS_COMPILER_TARGET_ARCHS)
                  endif
             endif
             ifdef T_A
                <rest of CONFIG_COMMON file> 
             endif

Janet