What's more important, the exit status of the context command is 0
(via echo $?) indicating that there was no problem at all! This
might turn out problematic as soon as documents are processed in a
batch run ... (like e.g. a regression test suite ;-)
*You* want to write a test suite for ConTeXt?
Well, not exactly ... this might be too ambitious an endeavour for one
person alone ;-)
I'm trying though to store a bunch of test cases locally which I
sporadically collect from the main mailing test whenever a bug report
shows up. If only to have something I can test my installation package
against ...
For the moment I'm mainly interested in whether these test cases
compile at all hence my remark about the exit status ... (After all,
if that can't be automated any further verification steps will be
pretty much useless I guess.)
Perhaps one could even integrate this requirement check into the
module loading code of the kernel. For example, one might enforce
that each valid module has to declare a field like
"minkernelversion" in its header ... just thinking out loud.
The problem with such systems is they lead always to
incompatibilities with older
ConTeXt installations (think about TeXLive) and we had one at the
end of last year
when Hans changed the multilingual interface to allow a persian
interface.
I agree that my suggestion would sacrifice backwards compatibility. At
the same time I'm not sure how much change to the MkIV kernel is
desirable given that MkII is considered frozen. I'm really in no
position to have an educated opinion on whether there should be as few
changes as possible or rather the occasional clear cut. It's just that
if you guys think that some clear cuts are due for MkIV anyway then
there will probably be never a better time than now to make module
loading more bullet-proof. As I was saying, I'm just thinking out
loud ;-)
Oliver
_______________________________________________
dev-context mailing list
[email protected]
http://www.ntg.nl/mailman/listinfo/dev-context
