Supporting different files at different sites ...

John Shott shott at
Mon Jun 18 17:25:18 PDT 2001

Bill and Mike:

I realize that you are on vacation and probably don't care about this stuff
right now ... and I'm not expecting that you'll read this now ... but I think
that I've been making progress on being able to support different source files
at different sites.

I thought that I'd try to write this down to see if if makes sense to you ...

At the moment, in any particular directory we have a set of java files.  For
simplicity, I'll assume that the name of the java files are and  Somebody at another site, might be happy with our,
but want to modify our to better meet their needs, and add a
third file called that does something that we don't currently

Our current file structure would be:


What I propose we create is a sub-directory called "site-specific" that would
include all of those files that weren't part of the "base distribution".  I
would propose to have a new structure that would look like: (assuming that mit
is the site having the different file names)


In this case, any site that is not mit should only compile files
and  For mit, however, they should compile the base, their,mit, and their,mit.
Note: the site-specific files end with ",sitename" note ".sitename".  In part
it is easier to handle if it is a comma rather than an extra dot.

I think that I've got the Makefiles modified (well, etc/Makefile and
auth/server/Makefile as test cases ...) to do the right thing.

The main requirement is that everyone who is compiling this stuff needs to
have the environment variable SITE set to their appropriate value.  For us,
this would be accomplished with the bash command "export SITE=stanford" either
on the command line or, preferably, in our .bashrc.

I've modified etc/Makefile so that it compiles FileOne.class from
site-specific/ (instead of the normal  Note:
site-specific/ doesn't exist ...

I have written three "implicit" rules that know how to make

1. The "base condition": If exists but
site-specific/,mit doesn't exist.  In this case, temporarily make
a copy of as site-specific/

2. The "only site-specific" condition: If site-specific/,mit
exists, but doesn't exisit.  Create
site-specific/ as a copy of site-specific/,mit

3. The "both" condition where exists and is a part of the base
distribution and site-specific/,mit exists and contains their
modifications.  In this case, we assume that the site-specific file takes
precedence and copy site-specific/,mit into file

Also, once the compilation takes place, these "intermediate" files are
automatically deleted ... so that the file structure won't be screwed up if we
do a "cvs commit", for example.  Note: also, it issues a warning if is newer than site-specific/,mit that it is going to
use the site-specific file.

In this case, the subdirectory named site-specific is both the repository of
the site-specific files as well as the "build directory" (that is, the
temporary location of the actual *.java files that are compiled ... although
all of the class files are stored in their normal location).

Note: site-specific would need to be "add"ed to cvs in any directory in-which
we wanted to store site-specific files.  However, if there are none, the
directory site-specific is actual created as a part of the build process.

Also, I've modified the Makefile in the source tree so that issuing a "make
all" will compile both all of the base files and all of the local-site-only
files ... without having to modify the Makefile.

(Note: this actually only took the addition of about 15 lines in etc/Makefile)
and the replacement of the specific naming of class files to be compiled
currently "OBJ = AuthServer.class AuthManager.class" in auth/server/Makefile
with about 5 lines that says "compile the class files for everything based on
*.java in auth/server as well as anything based on *.java,$(SITE) in
auth/server/site-specific where $(SITE) = my site.)

Final note: I think that it will also take very little work to allow
site-specific versions of various *.sql files, shell-scripts, etc.  I need to
look to see if it is also easy to do site-specific files in the "conf"
directories.  The one thing that I'm not sure that we can do is to have
site-specific Makefiles.  Of course, folks who have site-specific files have
no guarantees if the baseline stuff changes ... they will get the warning that
one of the baseline files changed, but it will be up to them to make sure that
their stuff works with our improvments.  At the very least, I'm hopeful that
this approach (or something like it) will allow us to allow for site-specific
differences in the context of a (hopefully) largely single codebase.

Thoughts, comments, etc. will be welcome when you return ... have a good week.



More information about the coral mailing list