1.5 Using csh aliases to create a Parallel Software Development Tree

Below is a set of C shell aliases that can be used to create a parallel software development tree.

1.5.1 Aliases for Managing Symbolic Links

Below are several csh aliases that can be helpful when managing a duplicate hierarchy that is implemented with symbolic links:

alias pt 'echo $cwd | sed s:${HOME}/Ptolemy:${PTOLEMY}:' alias ptl 'ln -s \Qpt\Q/* .' alias sw 'mv \!^ swap$$; mv .\!^ \!^; mv swap$$ .\!^' alias exp 'mkdir .\!^; sw \!^; cd \!^; ptl' alias rml '\rm -f \Q\ls -F \!* | sed -n s/@\$//p\Q'
alias mkl 'rml make*; ln -s \Qvpath\Q/make* .'

% cd ~/Ptolemy
% exp src
% exp domains
% exp ddf
% exp stars

The rml Alias

The rml alias removes symbolic links in the current directory. Without an argument, it removes all the visible symbolic links. Any arguments are passed on to the ls command. So, to remove all symbolic links, including those that are invisible, use the -a option:

% rml -a
You can also give file names as arguments to remove just some of the symbolic links:

% rml *.o

The mkl alias

Suppose you wish to compile your change to the DDFRepeater.pl file, as above. You will need to make an object tree. Assume you are on a Sun Solaris 2.x platform. You have created a parallel tree already in ~/Ptolemy/src (i.e. ~Ptolemy/src/domains/ddf/stars exists). Create the corresponding object tree:

% cd ~Ptolemy
% exp obj.sol2
% exp domains
% exp ddf
% exp stars
% pwd
/users/me/Ptolemy/obj.sol2/domains/ddf/stars
The directory in which you are now located contains symbolic links to the .o files and makefiles in the official Ptolemy tree. If you run make here, your replacement DDFRepeater.pl star will be compiled in place of the official one. If you run "make install", then a library will be created and installed in the directory ~/Ptolemy/lib.sol2, assuming this directory exists.

% pwd
/users/me/Ptolemy/obj.sol2/domains/ddf/stars
% ls -F
DDFCase.o@ DDFRepeater.o@ libddfstars.a@
DDFDownCounter.o@ DDFSelf.o@ make.template@
DDFEndCase.o@ DDFThresh.o@ makefile@
DDFLastOfN.o@ ddfstars.o@
(This assumes that the "official" Ptolemy has been rebuilt after being installed, otherwise the .o and .a files will be missing). Expand the makefile symbolic links:

% ls -l make*
lrwxrwxrwx 1 eal 56 Jul 14 11:30 make.template -> /users/ptolemy/obj.sol2/domains/ddf/stars/make.template
lrwxrwxrwx 1 eal 51 Jul 14 11:30 makefile -> /users/ptolemy/obj.sol2/domains/ddf/stars/makefile
Note that they point to the "official" makefiles. To make them point to the versions in your own tree,

% mkl
% ls -l make*
lrwxrwxrwx 1 eal 47 Jul 14 11:31 make.template -> ../../../../src/domains/ddf/stars/make.template
lrwxrwxrwx 1 eal 42 Jul 14 11:31 makefile -> ../../../../src/domains/ddf/stars/makefile
Now you can modify the make.template file in your own tree as you need.

1.5.2 Creating a Duplicate Hierarchy

Let's look at a complete example to see how these aliases can be used. Suppose you want to modify an existing file that is part of the kernel for the SDF domain. You will need a private copy of the file that is writable. This allows you to make your changes without affecting the "official" version of Ptolemy. In order to test your change, you will have to build a private version of the interpreter ptcl or the graphical interface pigiRpc.

% mkdir ~/Ptolemy
Then go into that directory and create symbolic links to all files in the corresponding "official" Ptolemy directory.

% cd ~/Ptolemy
% ptl
You will want to have a private version of the lib.$PTARCH directory so that you won't modify the "official" version of any library or object files. % cd ~/Ptolemy % exp lib.$PTARCH
(This assumes your $PTARCH environment variable is set). You will also want a private obj.$PTARCH directory for the same reason. In this example, the tree is expanded down to the sdf directory:

% cd ~/Ptolemy
% exp obj.$PTARCH % exp domains % exp sdf If you are modifying code in the sdf/kernel directory, then you will want to expand it as well. Once expanded, you will want remove the make.template and makefile links (which point to the "official" Ptolemy files) and replace them with links that use relative paths to refer to your private versions of these files (in case you make changes to them): % exp kernel % mkl If you make changes in the sdf/kernel directory, then there is a good chance that object files in sdf/dsp and other directories will also have to be recompiled. Thus, you will want to expand these directories (and any subdirectories below them) as well. Remember to replace the make.template and makefile links as in the sdf/kernel directory. % exp dsp % mkl % exp stars % mkl Because of the way symbolic links work, it is important to remove the links for the .o and .a files in the directories you have just created. You can do this by issuing a make realclean command in the obj.$PTARCH/domains/sdf directory. This will recursively clean out all the subdirectories. You could also do this manually by issuing a rml *.o *.a command in each directory.

% cd ~/Ptolemy
% exp src
% exp domains
% exp sdf
% exp kernel
At any point after this, it is possible to switch back and forth between private and "official" versions of these directories with the sw alias. In fact, you just used it (as part of the exp alias) to switch to the private versions of the obj.$PTARCH, lib.$PTARCH, and src directories.

% cd ~/Ptolemy/obj.$PTARCH/domains/sdf/kernel % make install To make a version pigiRpc (or better yet, ptinyRpc) with your changes, % cd ~/Ptolemy/obj.$PTARCH
% exp pigiRpc
% mkl
% make ptinyRpc

1.5.3 Source Code Control

At the present time, at Berkeley, the Ptolemy group uses SCCS for source code control. This means that each directory with source code in it contains a subdirectory called SCCS. That subdirectory is not distributed with Ptolemy, but if you are starting your own development expanding on Ptolemy, you may wish to use a similar mechanism. We assume here that you are familiar with SCCS, which is a standard Unix facility.

% pwd
/users/me/Ptolemy/src/domains/ddf/stars
% sw DDFRepeater.pl
mv: cannot access .DDFRepeater.pl
% ls -a
./ DDFEndCase.h@ DDFThresh.cc@
../ DDFEndCase.pl@ DDFThresh.h@
.DDFRepeater.pl@ DDFLastOfN.cc@ DDFThresh.pl@
DDFCase.cc@ DDFLastOfN.h@ SCCS@
DDFCase.h@ DDFLastOfN.pl@ TAGS@
DDFCase.pl@ DDFRepeater.cc@ ddfstars.c@
DDFDownCounter.cc@ DDFRepeater.h@ ddfstars.mk@
DDFDownCounter.h@ DDFSelf.cc@ make.template@
DDFDownCounter.pl@ DDFSelf.h@ makefile@
DDFEndCase.cc@ DDFSelf.pl@
Note the symbolic link to the "official" SCCS directory. This will not be present if you are using the distributed Ptolemy and have not created it. Assume, however, that you have put this directory under SCCS control (or someone else has). Then you can create an editable version of the DDFRepeater.pl star with the command:

% sccs edit DDFRepeater.pl
1.24
new delta 1.25
76 lines
The sccs utility tells you the latest version number (1.24) and assigns you a new version number (1.25). You can now edit the file safely (nobody else will be allowed by sccs to edit it). When you are done and have fully tested your changes (and obtained clearance from the Ptolemy group if necessary), you can check the file back in:

% sccs delget DDFRepeater.pl