Re: [Plplot-cvs] CVS update notice (plplot/examples/tcl)

[Maurice L. <mj...@ga...>]

Vince Darley writes:
 > On Fri, 20 Dec 2002, Maurice LeBrun wrote:
 > > It's a bad thing to have in there, b/c the version of tclIndex produced by the
 > > build is always going to be definitive.  Thus the cvs copy of tclIndex is
 > > going to be nearly constantly out of date.  So yeah, if you don't want to
 >                     ^**********^
 > 
 > Sorry, I didn't realise the Tcl examples directory was nearly constantly
 > under development ;-)

When I said "out of date", I am talking from a cvs perspective.  When the
package is built, it will produce a new version of tclIndex every time an
example program is changed *in any way*.  Then next time you run 'cvs status'
or 'cvs -nq update' you will see that tclIndex needs to be checked in, even
though there may be no actual changes of consequence to it.  So then you
either ignore the false out-of-date-ness (bad, because 1/100 times it may not
actually be false), or you commit a new version of tclIndex every time you
make any change no matter how trivial to any example program (stupid).

This kind of situation is dangerous and easily avoided.

 > I do think it is a shame that you suggest such a unix-centric approach,
 > however.  It doesn't encourage non-unix developers when they see a
 > supposed build directory littered with weird files that don't really
 > belong there, and are harder to keep up to date by virtue of being in an
 > out of the way place.

I'm coming from a tool-centric approach, i.e. make & cvs & Tcl, as well
as the general rule of thumb that generated files do not belong in a
cvs repository.  It's ok to make some exceptions to this but tclIndex
files are easy & quick to build; you just need a tcl shell of the
right type which you are guaranteed to have at the end of the build.

 > It is already a hassle building plplot on any other platform, especially
 > with random configuration, include and version changes which need to be
 > followed so I don't really understand why you're trying to raise the bar
 > even higher.

I don't understand what it is about cygwin that makes including generating
a tclIndex so hard.

 > As Alan points out, of course all this stuff *can* be generated by me or
 > others or for a distribution, but the question is *why*.  If someone is
 > actually fixing some Tcl code, presumably they know enough about Tcl to
 > run 'auto_mkindex' when needed and commit the change.  That way the job
 > happens just once, and by someone who knows what they're doing.  Instead
 > the position which seems to be advocated is that this should be encoded
 > with some rule in some makefile or configuration file (or, god forbid,
 > some special makefile to build a distribution).

Things that can be automated, should be automated, because the fewer petty
details a developer has to remember, the less mistakes one makes, and the
better one can focus on real issues.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)