• Introduction



• Inter-operable localdev setup



• Procedure to make baselines inter-operable as source areas

The localdev development environment consists of a set of scripts that are used to manage source files within an arbitrary number of related production areas. This page shows how a localdev 1.x production area can be made to look like a localdev 2.x source area. This is done by configuring a localdev 2.x source area with a special interop option. Figure 1 shows what this looks like.

• Heavy solid lines show which directories correspond. With this setup, these are actually the same directories in the filesystem. Symbolic links make them seem to be in two different places (under both awipsHub and awipsHub2).
• Light dotted lines show the usual links between baselines and staging areas. These remain unchanged in 2.x, except we're calling these areas by the more general terms source and build areas.
• A 1.x production area has an explicit directory in the filesystem, and can contain a number of baselines beneath it. They always contain 'base' and 'stage' directories, beneath which lie top-level baseline and staging area directories (or links to them).
• A 2.x production area has a single source area directory containing what is equivalent to a single baseline. A single top-level source directory exists within it. In this setup, we continue to use the 'base' directory from 1.x for inter-operable source areas, and add a 'master' directory that contains links to the subdirectories in 'stage'.
• Hubs are distinct -- 2.x hubs are incompatible with 1.x hubs. All correspondences are at a lower level.
• Staging areas correspond to build areas. In 1.x, staging areas are always accessible through spoke directories. In 2.x, build areas are referenced directly, rather than through a spoke directory. This setup uses the staging area locations for inter-operable build areas.

This setup is identical to the normal 2.x setup, except that it includes additional steps for making existing baselines and staging areas accessible as 2.x source and build areas. You can create and use 2.x-only source and build areas in addition to inter-operable ones after completing this setup.

1. Replace localdev PATH setup in your shell setup file. Note that there is a new setup file for localdev 1.x in the ~fxa/localdev2/etc directory. Use of these standard setup files will ensure your account's compatible with future localdev releases.
   
   for CSH: add the following to your .cshrc file at a point AFTER you set your command path variable:

   if ($?LDEV2 == 1) then
      # Access localdev 2.x
      if (-e ~fxa/localdev2/etc/csh_setup2) \
         source ~fxa/localdev2/etc/csh_setup2
   else
      # Access localdev 1.x
      if (-e ~fxa/localdev2/etc/csh_setup) \
         source ~fxa/localdev2/etc/csh_setup
   endif
   alias ldev2 'setenv LDEV2 1'
   alias ldev1 'unsetenv LDEV2'
   

   
   
   
   for KSH: add the following to your .profile file at a point AFTER you set your command path variable:

   if [[ $LDEV2 = 1 ]]
   then
      # Access localdev 2.x
      if [[ -e ~fxa/localdev2/etc/ksh_setup2 ]]
      then
         . ~fxa/localdev2/etc/ksh_setup2
      fi
   else
      # Access localdev 1.x
      if [[ -e ~fxa/localdev2/etc/ksh_setup ]]
      then
         . ~fxa/localdev2/etc/ksh_setup
      fi
   fi
   alias ldev2='export LDEV2=1'
   alias ldev1='export LDEV2='
   

   
   
   
   REMOVE ALL OTHER localdev manipulation of command path from your shell setup (.cshrc, .profile, and anything they source). You can leave in any mechanisms you have for setting LOCALDEV_TASK to switch between development areas. It's just the PATH manipulation that is being replaced.
   Look for lines like:

   source ~fxa/localdev/setup-localdev
   

   or something like:

    
   set newpath = ( ~fxa/localdev/access/nwscm/bin )
   set newpath = ( ~fxa/localdev/bin $newpath )
   foreach dir ($path)
      if ($dir !~ */nwscm/bin && $dir !~ */localdev/bin) then
         set newpath = ( $newpath $dir )
      endif
   end
   set path = ( $newpath )
   

   
   
   You'll then be able to switch between localdev 1.x and localdev 2.x by invoking either ldev1 or ldev2, and then sourcing your setup file (source ~/.cshrc or . ~/.profile).
   
   Try it. Source your revised shell setup file (source ~/.cshrc or . ~/.profile), and then run ' dv-help -V ' to see which version you're running. You should get either version 2.0 or version 1.10.>
   
   
2. Set your account's localdev scope.
   Set your localdev scope by running  dv-scope -m . You will be prompted to take the following actions:
   
   

   a) Specify an Email address that can be used to notify you when and if
      one of your file locks have been severed.
   
   b) Indicate which localdev hubs you want to be held within your localdev
      scope. This will affect how may localdev mode values you can select from.
      -- include awipsHub2
   

3. Set your shell's group.
   If you're not in the fxalpha group by default, then you'll need to set this manually for each shell within which you use localdev for AWIPS development. Run  newgrp fxalpha  to set it.




---



THE FOLLOWING APPLIES TO DEVELOPMENT ACCOUNTS -- SEE THE SEPARATE PROCEDURE BELOW FOR WORKING IN THE fxa ACCOUNT TO MAKE INTER-OPERABLE SOURCE AND MASTER BUILD AREAS.

The awips5.2.1 and RSA5.1.2 source areas are used as an example below. Replace 'awips5.2.1' and 'RSA5.1.2' wherever they appear with other appropriate names if linking to a different source areas.



---




4. Make 1.x private staging areas inter-operable as 2.x private build areas.
   You can use this step on any existing staging area. If you have some staging areas that you'll never run nwscm commands on, such as those located on your local machine's scratch disk, then you can either make them inter-operable or instead recreate them as shown in step 5.
   
   First, select the source area that the build area will be linked to as the current development area
   (setenv LDEV_MODE SOURCE_awips5.2.1).
   
   If the staging area is contained WITHIN your account's spoke directory -- not just symbolically linked to it -- then running  dv-buildarea -I spokepath/awips5.2.1/stage/stagename stagename 
   where:
   • spokepath=the path to your spoke directory,
   • stagename=the staging area name
   
   will make the staging area at spokepath/awips5.2.1/stage/stagename accessible as a private build area having name stagename located at spokepath/awips5.2.1/stage/stagename.
   
   If the staging area is OUTSIDE your account's spoke directory -- in which case it is symbolically linked to it -- then running  dv-buildarea -Ispokepath/awips5.2.1/stage/stagename  stagepath stagename 
   where
   • spokepath=the path to your spoke directory,
   • stagename=the staging area name,
   • stagepath=the path to the actual staging area
   
   will make the staging area that is accesible through spokepath/awips5.2.1/stage/stagename and that actually resides at stagepath accessible as a private build area having name stagename located at spokepath/awips5.2.1/stage/stagename.
   
   
5. Create new (2.x-only) private build areas
   If you want to create one or more new private build areas, then use dv-buildarea to do so, as follows:
   
   If you're replacing an existing staging area, then make sure you have removed all of your file locks (using 1.x dv-commit and dv-revert), and then remove the staging area using dv-rmstaging.
   
   First, select the source area that is to be linked with this private build area as your current development area (setenv LDEV_MODE SOURCE_RSA5.1.2).
   
   Running  dv-buildarea path/buildname modename  will create a private build area having name buildname at location path/buildname with a mode named modename. You can put your build areas wherever you want. You may want to place these build areas on local disks -- they typically give better build performance.
   
   
6. Synchronize private build areas
   Synchronizing each build area ensures that they contain all associated source area directories and links to all source area files. Doing so at this time is not required, but is recommended.
   
   For each build area that you created or made inter-operable above, set it as your current development area ( setenv LDEV_MODE modename ), change your current directory (CWD) to the top-level directory of the build area, and then run  dv-sync -R .  to synchronize the entire area.
   
   
7. Repeat above steps (4 - 6) for other build areas.
   If you want to create or make inter-operable any additional build areas, then repeat the above steps now or at any time. Areas that are not inter-operable with 1.x can easily be moved using dv-sourcearea or dv-buildarea. You can run  dv-scope  to list available source area mode names. They all begin with "SOURCE_".
   
   
8. Set current development areas.
   Run  dv-scope  to get a summary of your defined modes. Whenever you want to use a window for localdev development, you will need to select a current development area to work in. You do this by setting the environment variable LDEV_MODE to a mode name. You can either do this in several ways:
   • manually (setenv LDEV_MODE modename  in csh; export LDEV_MODE modename incsh)
   • through a dev alias (alias dev 'setenv LDEV_MODE \!*') -- recommended
   • set up an alias or script to set this variable along with build variables.
   In order to ease setup for localdev 1.x users, localdev 2.x honors LOCALDEV_TASK settings if LDEV_MODE has not been set, and if defined 2.x mode names match 1.x task names.
   
   
9. Select global settings.
   List your account's global settings by running dv-select. These settings apply to all development areas that you are working in. Customize these as desired using dv-select. The defaults work well. Leaving quiet-output-mode-toggle set to the default 'on' value, in particular, is recommended.
   
   
10. Configure source and build areas.
    Source areas almost always require custom configuration. As a developer, you'll want to view this configuration to see how it will behave. Build areas can also be configured. Build area configurations contain information that is useful for importing and merging files from external sources. These features are described in the tutorial.
    
    

Procedure to make baselines inter-operable as source areas

1. Create localdev 1.x baseline, if desired.
   If you are creating a new source area that is to be inter-operable, then create it under localdev 1.x, as you normally would. See localdev 1.x documentation for guidance, if you need it. Create a production area in a 1.x hub (like awipsHub), if you need it. Then either create a fresh copy an existing baseline into it. If you do copy, make sure that you use the archive option, and that you set umask to 0 before running it. Go ahead and create some master staging areas for the new baseline. Doing this now will allow you to make them inter-operable in step 5, below.
   
   Given the way we typically split baselines and staging areas across filesystems, the following procedure is typical, where '###' represents the version of awips that we are using to initially populate the new baseline.
   • As fxa, access localdev 1.x: ldev1; source ~/.cshrc
     (and then reset your TERM variable, if it was clobbered)
   • Create new localdev tasks for each platform:
     (Note that the new task names match master staging area names, and have been standardized as version-platform.)
     • cp ~/.localdev_###-linux ~/.localdev_5.2.1-linux
       (and edit the new file, changing the filename in the header, the currentProduct setting to awips5.2.1, and clearing settings for currentBaseline and currentStaging by removing everything to the right of the '=')
     • cp ~/.localdev_###-hp ~/.localdev_5.2.1-hp
       (and edit the new file, changing the filename in the header, the currentProduct setting to awips5.2.1, and clearing settings for currentBaseline and currentStaging by removing everything to the right of the '=')
     • Select the new task: setenv LOCALDEV_TASK 5.2.1-hp
   • Create a production area: dv-mkarea -t awips ~fxa/awipsHub awips5.2.1
     (not overriding template properties, but using a non-default location of /home/eagle14/awips_build/awips5.2.1)
   • Select the new production area: dv-select -P awips5.2.1
   • Create a new baseline: dv-mkbase -s awips
     (not overriding any properties)
   • Clear umask: umask 0
   • Overwrite the baseline with a copy of an existing one:
     cp -af /home/eagle14/awips_build/awips###/base/awips \     /home/eagle14/awips_build/awips5.2.1/base/awips
     (this will overwrite all .dv* and other configuration files)
   • Restore umask: umask 002
   • (Defer repair of the copy until later in this procedure)
   • Create an HP master staging area: dv-mkstaging -N 5.2.1-hp awips
     (override the default location with: /mstage/awips/5.2.1-hp)
   • Switch to the linux task: setenv LOCALDEV_TASK 5.2.1-linux
   • Create a linux master staging area: dv-mkstaging -N 5.2.1-linux awips
     (NOT overriding the default location)
   • The two new tasks are each now set to select the appropriate master staging area as the current development area.
   
   
   
2. Access localdev 2.x.
   Invoke the 'ldev2' alias and 'source ~/.cshrc' to make 2.x accessible. The ldev2 alias was created in the fxa account as a simple way of setting an LDEV2 variable appropriately.
   
   
3. Create a 2.x hub.
   If you need a 2.x hub other than awipsHub2, then use dv-hub to create one, as follows:
   
   Running  dv-hub path/hubname  will create a hub having name hubname located at path path/hubname. You'll want to make hubs accessible across your local area network.
   
   Set the new hub as your current development area (setenv LDEV_MODE HUB_hubname) so that you can create a source area within it.
   
   
4. Make a 1.x baseline inter-operable as a 2.x source area.
   Assuming you want to make some existing localdev 1.x baselines accessible as localdev 2.x source areas, then do so using dv-sourcearea, as follows:
   
   First, select the localdev 2.x hub that is to contain the source area as the current development area (setenv LDEV_MODE HUB_awipsHub2) if you have not done done so already. Running  dv-sourcearea -I ~fxa/awipsHub/awips5.2.1/base/awips awips5.2.1 
   where:
   • ~fxa/awipsHub/awips5.2.1=the path to the production area,
   • awips=the baseline name,
   • awips5.2.1=the production area name
   
   will make the baseline at ~fxa/awipsHub/awips5.2.1/base/awips accessible as a source area having name awips5.2.1 located at ~fxa/awipsHub/awips5.2.1.
   
   
5. Change the source area mode to 0775
   Check the mode and change it if necessary.
   ls -ld ~fxa/awipsHub/awips5.2.1/base/awips
chmod 0775 ~fxa/awipsHub/awips5.2.1/base/awips
   
   
6. Select the new source area
   Rerun dv-scope -m in order to make the source area's mode accessible to this account.
   
   Set the source area as your current development area (setenv LDEV_MODE SOURCE_awips5.2.1) so that you can create a master build area within it.
   
   
7. Repair the new source area
   Run  dv-repair awips5.2.1  to update the baseline so that it can be functional as a source area in localdev 2.x. Depending on how clean the 1.x baseline is, this may take several iterations. If you change your CWD to be within the source area, you can repair the baseline a chunk at a time by specifying a directory name (as in  dv-repair awips5.2.1 src/D-2D , where src/D-2D is the relative path to the directory defining the subset.
   
   
8. Check for duplicate master staging area names.
   The names of master build areas owned by a single account must be unique. This requirement did not exist for master staging areas in 1.x. If need be, simply rename a master staging area by renaming it and its link within its 1.x production area to something unique.
   
   The awips5.2.1 production area:
   
   production area link at: ~fxa/awipsHub/awips5.2.1
   production area location: /home/eagle14/awips_build/awips5.2.1
   staging areas at:
      5.2.1-hp: /mstage/awips/5.2.1-linux (linked to production area)
      5.2.1-linux: /home/eagle14/awips_build/awips5.2.1/stage/5.2.1-linux
   
   Other master staging areas will have to undergo name changes like:
       gcc-hp -->  5.x.x-hp
    linux  -->  5.x.x-linux
   
   
9. Make 1.x master staging areas inter-operable as 2.x master build areas
   Assuming you want to make some of its existing localdev 1.x master staging areas accessible as localdev 2.x master build areas, then do so using dv-buildarea, as follows:
   
   First, select the localdev 2.x source area that is to contain the master build area as the current development area, as described (setenv LDEV_MODE SOURCE_awips5.2.1) if you have not done so already.
   
   Assuming that the 5.2.1-linux staging area is contained WITHIN its production area -- not just symbolically linked to it -- then running  dv-buildarea -I /home/d-2d/fx-alpha/awipsHub/awips5.2.1/stage/5.2.1-linux 
   where:
   • /home/d-2d/fx-alpha/awipsHub/awips5.2.1=the path to the production area,
   • 5.2.1-linux=the staging area name
   
   will make the staging area at ~fxa/awipsHub/awips5.2.1/stage/5.2.1-linux accessible as a master build area having name 5.2.1-linux located at ~fxa/awipsHub/awips5.2.1/stage/5.2.1-linux.
   
   Assuming that the 5.2.1-hp staging area is OUTSIDE its production area -- in which case it is symbolically linked to it -- then running  dv-buildarea -I/home/d-2d/fx-alpha/awipsHub/awips5.2.1/stage/5.2.1-hp /mstage/awips/5.2.1-hp 
   where:
   • /home/d-2d/fx-alpha/awipsHub/awips5.2.1=the path to the production area,
   • 5.2.1-hp=the staging area name
   • /mstage/awips/5.2.1-hp=the path to the actual staging area
   
   will make the staging area that is accessible through ~fxa/awipsHub/awips5.2.1/stage/5.2.1-hp and that actually resides at /mstage/awips/5.2.1-hp accessible as a master build area having name 5.2.1-hp located at /mstage/awips/5.2.1-hp. You can run this command once for each master staging area that you want to be inter-operable.
   
   
10. Configure new source areas
    You need to configure each source area that you have made accessible under localdev 2.x. The configuration mechanism used by localdev 2.x is different than that used by localdev 1.x. Assuming that a configuration template already exists, apply it to this source area by running ' dv-config -sa awips'.
    
    
11. Populate new source areas
    You need to populate each NEW source area that you have made accessible under localdev 2.x. Refer to the localdev tutorial for more information about populating source areas. This step does not apply to nter-operable source areas, because they are already populated.
    
    
12. Synchronize master build areas
    Synchronizing each build area ensures that they contain all associated source area directories and links to all source area files. Doing so at this time is not required, but is recommended.
    
    For each build area that you created or made inter-operable above, set it as your current development area ( setenv LDEV_MODE MASTER_stagename ), change your current directory (CWD) to the top-level directory of the build area, and then run  dv-sync -R .  to synchronize the entire area.
    
    
13. Change source area state
    When a new source area is ready for use, you need to make it accessible to developers for use. Do this by changing its state with dv-state. Refer to the tutorial for information about supported states. It is common to set a new source area to open state, allowing developers complete access to it, with  dv-state open .