WG> The CVS checkout (or CVS update) operation will not pull the
 WG> contents of the default configuration files (as found in
 WG> install_tree), the archivers (in dist), etc.

why not?

 WG> For those you need max-3.03-etc.tar.gz. That file remain
 WG> relatively static, howerver.

can't they be submitted to the tree just like everything else? that way,
when someone pulls the tree, they get everthing they need and/or don't have
already?

 WG> I'm suggesting the wipe/build operation as opposed to make
 WG> clean, because make clean isn't programmed to wipe away
 WG> source which has been deprecated,and because make install
 WG> will not overwrite existing configuration files.. but the
 WG> templates have fewer bugs in them now (i.e. the menus work
 WG> out of the box).

ahh... wipe/build is also easy enough... i just used mc and deleted the
entire maximus source directory in my /opt directory and then cvs'd the
whole thing down again... i guess i still have to get that etc file, though
;-(

[time passes]

i'm pulling it from your site, now...

 WG> Also, I'm paranoid, as there have been a LOT of changes in
 WG> the last few days, and if the make clean rules are broken in
 WG> some subtle way, you could be in for a world of hurt (e.g.
 WG> changed dynamic link paths, changed some structure sizes,
 WG> etc).

hummm... guess i've been spoiled by so many other source based stuff that
had working make clean and configure/autoconf stuff...

 WG> FWIW, I haven't tested just "make squish" in quite some time,
 WG> although "make build" (which builds max *and* squish) has
 WG> been well tested, as has "make install".

doesn't make build use the same part as the make squish portion??

 WG> Let's just say I'm following the OpenSource mantra "Release
 WG> Early, Release Often".

that one is ok...

 WG> Either that, or the Gates mantra "Let your users do the
 WG> testing for you".

ugh!

)\/(ark