public inbox for mauve-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Toni Masse <toni.masse@ateji.com>
To: tromey@redhat.com
Cc: mauve-discuss@sources.redhat.com
Subject: Re: about Jacks' functioning
Date: Thu, 01 Jun 2006 10:47:00 -0000	[thread overview]
Message-ID: <447EC5A2.5010403@ateji.com> (raw)
In-Reply-To: <m3bqtvb9e3.fsf@localhost.localdomain>

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

      reply	other threads:[~2006-06-01 10:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-27 17:03 Toni Masse
2006-05-18 16:18 ` Tom Tromey
2006-06-01 10:47   ` Toni Masse [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=447EC5A2.5010403@ateji.com \
    --to=toni.masse@ateji.com \
    --cc=mauve-discuss@sources.redhat.com \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).