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 mjl@...
Research Organization for Information Science and Technology of Japan (RIST)