On 09/20/11 13:38, Steve Havelka wrote:
Excuse my bluntness: that sounds like a terrible idea. Tcl is huge compared to fossil, and certainly not installed everywhere by default.
Which is why it would have to be integrated in the fossil source, built from source, and attached to fossil at buildtime. No runtime dependencies. Alternatively, if jimtcl was the way to go, we're talking about a 200k increase in the fossil binary, no external dependencies at all. Does that sound so bad?
And for what benefit? To have a full-blown programming language built in?
It's the other way around. Proper tcl integration would also mean to turn fossil around, so that fossil is actually the library, allowing to call any fossil command (and, in some cases, even finer-grained controls) from within that other PL.
> That of course isn't a benefit in itself. If an organization needs
some sort of sophisticated processing attached to a hook, e.g. some verification on commits, let them call an external program, a shell script, a tcl script, whatever.
It can't do so portably. To do that, it would have to introduce a compat layer handling the platform differences of windows/unix/... Then again, it could use an existing compat layer. Like Tcl.
> Embedding an interpreter into Fossil
itself, to run code called by the hook, seems like entirely the wrong approach.
Again, the right way to integrate those two would be to make fossil a library. If done properly, bindings for other languages can emerge naturally. And of course there needs to be a compile-time option to strip all that support in case you want a real slim fossil binary. As Stephan said in another context, it's a herculian task. But one worth undertaking IMO.
Regards, -Martin _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
