On Tue, Nov 29, 2011 at 8:40 AM, Gapps + local IMAP
On Mo, 2011-11-28 at 18:00 +0100, Chris Kühl wrote:
> On Wed, Nov 16, 2011 at 2:39 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> > No, that's what I was looking for. When you say "command line
> > does that mean that there will be an exec() involved? Would that start
> > the same binary or something else?
> Yes this was going to be my proposal.
> > The advantage of the exec() is that the new process is much cleaner. The
> > downside is that it is harder to implement (How does the forking process
> > find the "right" executable?
> I believe the place for the "helper" sync binary would be in the
> libexec directory: /usr/libexec/syncevolution/sync-session for
Please also add an env variable which overrides that default location.
The nightly testing needs that because it runs with an installation that
was made with DESTDIR and thus doesn't have the files in the hard-coded
> > How does injecting valgrind into the new
> > binary work?)
> Valgrind can follow child processes with --trace-children=yes and
> create a log-file per process by inserting %p in the log-file name.
Duh, of course.
[fork + function call from main()]
> This is how I originally intended to implement this till I started
> looking into it a little more and asking around. To me, the potential
> problems seem to outweigh the advantages.
Your concerns mirror my own concerns, so agreed, let's do the fork+exec.
Ok, I'll proceed in that direction and post a more detailed plan once
I do a little more poking.