This is the mail archive of the
mauve-discuss@sourceware.org
mailing list for the Mauve project.
Re: about Jacks' functioning
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