[on codalist particularly for portability suggestion #4, but also #3,
which I think really should be part of the coda distribution, even if
gui tools that use it aren't.]
I'm glad you did this; thanks for making the class project code
available. I hope my comments are helpful.
I tried to build this on FreeBSD (4-stable, more or less). I had
several problems. Basically the code uses ulong, and the Makefile
seems slightly broken. Patches at end for what I did to get it to
compile.
Build/portability suggestions:
1. Use autoconf/automake, to autodetect posix threads etc, and provide
install targets, --prefix and so on.
2. stick to standard types. Since this uses gtk, you might use
guint32 instead of ulong. (I'm guessing that ulong is usage
specific to GNU/Linux.) (I'm glad you used gtk - that part
required zero effort on my part, and the gtk-config script worked
as intended.)
3. Structurally, it would be really cool to see a library which can
fetch info, separately from the GUI processing, so scripting
languages, etc. could use this same back-end code. It looks like
some of this separation is present, but I think it would be good to
have a more explicit separation, and even build a library (with
libtool, perhaps) for this part.
4. There are venus ioctl and rpc2 defs in the source tree. I realize
that these are files that rpc2 and coda might not install in
$(prefix)/include, but this is a sign that those pacakges perhaps
should install include files for those things that are
5. I got lots of warnings when compiling. If this compiles cleanly on
GNU/Linux, I can do this again and mail them to you, but I'd
recommend doing builds on a least one BSD variant as well.
Usability
1. The program appears to have a serious file descriptor leakage
problem. After about 10-20 minutes, I started getting 'too many
open files in system' messages. I couldn't even run 'killall
codavis'. Fortunately I had some bloatware running, and exiting
that and typeing !k<ret> quickly let me win the race for file
descriptors.
2. I set up with one volume, and (I think - I don't want to run this
again until the fd leak is fixed) got a blue ? for status.
Tooltips showed me #cml entries, which was nice. But I didn't get
any obvious visual feedback on whether cml was =0 or not, etc. (I
was write-disconnected the whole time.) The README doesn't
explain the designed behavior - I'm not sure what was intended.
Having to mouse over the GUI IMHO defeats the purpose.
Greg Troxel <[EMAIL PROTECTED]>
--- codavis/src/af.h Thu Nov 29 00:34:16 2001
+++ codavis.build/src/af.h Thu Nov 29 09:38:01 2001
@@ -14,6 +14,8 @@
#define __AF_H__
#include <sys/types.h>
+typedef unsigned long ulong;
+
#include <sys/stat.h>
#include <unistd.h>
#include <stdlib.h>
--- codavis/src/Makefile Wed Nov 28 18:06:39 2001
+++ codavis.build/src/Makefile Thu Nov 29 09:28:26 2001
@@ -18,7 +18,7 @@
#USER_LINK_FLAGS = -lpthread
#endif
-USER_LINK_FLAGS = -lpthread
+USER_LINK_FLAGS = -pthread
#GTK_INC_FLAGS = -I/usr/include -DNEED_GNOMESUPPORT_H -I/usr/include/gtk-1.2
-I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include
#GTK_LINK_FLAGS = -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -lart_lgpl -lgdk_imlib
-rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -lgthread
@@ -45,7 +45,7 @@
$(CC) $(CPPFLAGS) $(CC_FLAGS) -c $(@:%.o=%.c)
$(CODAVIS_ALL): $(CODAVIS_OBJS)
- $(LINK_USER) -o $@ $(CODAVIS_OBJS) $(GTK_LINK_FLAGS)
+ $(CC) $(LINK_USER) -o $@ $(CODAVIS_OBJS) $(GTK_LINK_FLAGS)
%.o: %.c
$(CC) $(CPPFLAGS) $(CC_FLAGS) -c $(@:%.o=%.c)
