You are touching on an important point here, and thanks for bringing it up.
> Hi Pedro -
>
> I think our experience trying to get the demo together pointed out a lot
> of problems. One of them in my opinion is our current configuration
> management procedures. I feel responsible for most of this because it seems
> that the current procedures support the Georgia Tech style of development
> much more than the ISI style [which is not surprising considering they
> were developed at gatech], and I would like to make them a little more
> democratic :-) The symptom that leads me to believe there is a problem is
> that ISI does not use the existing CM during development, prefering to use
> your own methods. The consequences of this are both duplication of effort
> (since you guys typically build Makefiles by hand anyway) and a synchronization
> bottleneck when we try and adapt new packages into the existing CM scheme.
>
We have not completely adapted to the new style of development. Sometimes we
use objectcenter, sometimes just plain emacs and gmake, and sometimes we
create Makefiles by hand. We want to move to a scheme where we can use
objectcenter for development of individual components, and gmake (with
Imakefiles) for building all the tools. We don't want to hack Makefiles
ourselves.
The reason that we used plain Makefiles during the development of the demo is
that we knew that the Makefiles that Ewald had built would yield working
servers and clients, and we couldn't coerce the Imakefiles to properly link
the servers and clients.
> I know that the current set-up is somewhat unwieldy and I would like your
> opinions on how to make it better. So if I can, I'd like to explain what I
> think is the main point of contention between the 2 development styles
> and then follow it with some questions to try and figure out what your
> requirements are. That way maybe we can discover the reason for the problems
> and come up with a better solution that makes both ISI and Georgia Tech
> comfortable using unified CM procedures during development.
>
I think the main point of contention is that we don't know how to construct
Imakefiles that work properly. There seem to be several kinds of Imakefiles,
some of which we understand better than others:
- Imakefiles to go down the tree: we understand those (just add new directory
names).
- Imakefiles to build .o files that get used in libraries: we understand those
a bit, because there are lots of examples of those.
- Imakefiles to build cpp executables: also understand them a bit, because
there are some examples now.
- Imakefiles to build client/server executables: don't understand at all how
to do these ones.
The other thing about Imakefiles that we don't understand is how to re-build
the world incrementally. Doing a gmake World works, but takes a very long
time. Sometimes we just want to rebuild some libraries, and then executables
to try things out.
> The main point of contention as I see it is our use of Imakefiles.
> In the current scheme, Imakefiles run the show since the structure of the
> MM source tree is encoded in many of the imake macros, and all of the version
> control and directory partitioning is really governed by these macros.
> Questions:
> Q) I know you guys use ObjectCenter during development and we
> don't. Is ObjectCenter uncomfortable with Imakefiles? Pablo
> had mentioned before that it uses "project" files which seem
> to have a much different structure than Makefiles
> (and Imakefiles).
>
We think that objectcenter is a big win, and want to continue using it. We
haven't been using it lately, but we want to go back to use it.
Objectcenter uses project files, which list the sources or binaries to build a
program, together with libraries to build it. There are places to put all
kinds of flags also. Once the project file is set up, it behaves like a
makefile, but as you said the structure is different from Makefiles or
Imakefiles.
What we want to do here is construct .proj files for some of the executables
that we care about, and put those in SCCS.
> Q) Do you guys find the imake macros that Ga Tech has put together
> to support the MM source tree lacking or unusable? I know
> they're a hack and there are a ton of them. Could you use
> Imakefiles if these macros were documented better (or rather,
> documented at all)? The Corba/Cpp subdirectory hacks come to
> mind as something that might be a conceptual mismatch during
> development in the environments you guys employ.
>
The Imake macros are probably OK, we just don't know what they do. I think
only you know what they do. The best way to learn about them is the way we've
been doing it, ie, with examples. Eventually we'll have enough examples to
get by. Of course, the problem is that if you switch jobs one day, we'll be
in bad shape.
> Q) Is the inclusion of all of the Imakefiles in package configure
> too Draconian? That is, does gatech's "ownership" of all
> of the Imakefiles impede your development progress [since
> you guys can't check in/check out Imakefiles to make rapid
> adaptation and extension during development].
>
This is inconvenient. Now that we are learning to edit the Imakefiles, we
should put them in the package where they logically belong. It hasn't
bothered us a lot that they are in the config package, because if we need to
edit them, we toggle the read-only files and edit them. The only hassle is
that we need to send you the changes so that you can install them. In
general, if we need to edit something we edit it, the policy being that the
people who edit read-only stuff are responsible for making sure that the edits
are later on propagated via the proper channels.
> Q) Are there other differences that I haven't thought of?
>
Sometime soon we'll start working on the PC, which has its own version of
project files. I don't know enough about them to know how sophisticated they
are, but I know enough to know that they are different from ObjectCenter and
Unix Makefiles or Imakefiles. I think there is a version of plain Makefiles
for the PC, but I am not sure. The Visual C++ project files are manipuleted
via an interactive environment.
In summary, the highest priority for us regarding configuration management and
development environment is to go back to work in ObjectCenter. There are
several reasons why we like ObjectCenter:
- The link times in objectcenter are much much shorter.
- The editor and the compiler are well integrated, so that a single keystroke
puts emacs in the file and line where an error occurred.
- The debugger and the editor are well integrated. When looking at a stack
trace, you can ask with a single menu selection that Emacs visit the function
you care about.
- Breakpoints and stepping are a click away.
- Queries about the static structure of the program are easy (methods of a
class, etc).
- You can also inspect data structures in the debugger (I never do that, but I
know Pablo does).
I am surprised you people don't like it.
Pedro Szekely
USC/ISI, 4676 Admiralty Way, Marina del Rey, CA 90292
Phone: 310/822-1511, Fax: 310/822-0751
http://www.isi.edu/isd/szekely.html, http://www.isi.edu/isd/Mastermind