Sorry about the delay, too.
I've found some more answers a few weeks ago:
Tom Tromey a écrit :
> Toni> so I'd like to know how Jacks determines the compilation result (I've
> Toni> looked in jacks.tcl but I'm not sure about the exact behavior of
> Toni> Jacks),
>
> The proc named _exec_impl is used to actually invoke the compiler.
> This chunk invokes it:
>
> set cmd "exec $prog $prog_flags $prog_args > exec.out 2> exec.err"
>
> if {[info exists ::env(JACKS_EXEC_DEBUG)]} {
> puts stderr "JACKS_EXEC_DEBUG: $cmd"
> }
>
> eval $cmd
>
> This is wrapped in a 'catch' clause; Tcl's exec command throws an
> exception if the exec "fails", which in Tcl means that either it
> really fails (command not found or something) or that the command
> returns a non-zero exit status. I'm not sure how this works on other
> platforms.
>
For example, Tcl's exec command will fail if the executable calls java,
and the java program throws an exception. It works fine under Windows
using Cygwin, oddly it works if the executable is a batch file but not a
shell script.
> Toni> and why is a cvs client needed to generate the change file (with
> Toni> "jacks loggen" command)? Could I deactivate it?
>
> Yeah, I've always wondered about this myself. The jacks logging stuff
> seems a bit user-unfriendly. I'm sure it can be deactivated somehow.
>
> Tom
>
Actually CVS is used by Jacks to compare the revisions of the
logging/compiler_name.log file with the cvs diff command; that's how you
get an incremental list of transitions (clever, isn't it? ;) )
This means you just need to commit the log file each time you think you
passed an important step in the changes to the compiler; so the
compiler_name.changes file will
take it into account, and point out the transitions from this important
step to your last test.
This also means it doesn't make any sense to deactivate it :)
Cheers,
Toni