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

[Vince D. <vi...@sa...>]

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 ;-)

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.

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.

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).

As you can see, we seem to have some philosophical differences here about
what is truly 'simpler' and what is 'a pain in the neck'.  I'm sure your
position is perfectly accurate from a unix perspective.  So that's the
kind of user and developer you are likely to attract to plplot, and the
others will be more likely to be turned off.

I'll finish my rant now and commit the necessary changes so it is at least
possible to use plplot with Windows-Tk again.

cheers,

Vince.