On Saturday, August 13, 2011 10:36:28 AM Alan D. Salewski wrote: > Hi Paul, >
>
> Anything you can put in a Makefile is legit to put in a Makefile.am, so
> sure, you could use '%-' in there.
>
> With that said, using '%-' limits the portability of your Makefile.am to
> platforms that have a shell that supports it (bash, ksh, probably
> others), and compensating for that requires additional feature checking
> on the platform and steps to ensure that the found shell is the one
> being used when your Makefile gets run (as opposed to /bin/sh, which
> cannot be relied upon to be either bash or ksh).
>
> Instead of '%-', you could capture the pid of the backgrounded 'unoconv'
> listener and then use that to explicitly send signals to that process.
>
> > You would probably have
> > to insure that you were in the same shell as the one that started the
> > listener.
>
> To use '%-' you certainly would, but not strictly true if you capture
> the backgrounded pid using '$!'. Here's an (untested) example of what
> that might look like in a Makefile rule:
>
> convert-docs:
> unoconv --listener & \
> ucpid=$! ;\
> unoconv -f pdf some-document.odt && \
> unoconv -f doc other-document.odt && \
> unoconv -f jpg some-image.png && \
> unoconv -f xsl some-spreadsheet.csv ;\
> kill -15 $ucpid
Here is what I did:
#tricky code alert
#in a subshell save pid of subshell, ($$$$) becomes $$ in subshell.
#then exec the listener. result is listnener running
#in background with saved pid.
echo "echo "'$$$$'" >$@.pid ; exec unoconv --listener" | $(SHELL) &
#A bunch of unoconv commmands here
#kill the saved pid, i.e. the listener. $$ becomes $ in the shell.
-kill $$(<$@.pid)
#remove the pid save file
-rm $@.pid
The shell you are using must support $$, ';' and exec for this to work.
It this better or worse?
>
> One could store the pid value of the backgrounded 'unconv --listener'
> process to a file, but since that's gross in this context I won't say
> anything more about now that I've menioned that it's possible.
>
> The trailing backslash-newline sequences cause 'make' to invoke a single
> shell for all of that, which is required to preserve the $ucpid binding
> supplied to 'kill'. Note that the successive 'unoconf -f ...' commands
> only execute if the previous invocation succeeds, but the 'kill' command
> is always run.
>
> > What is the official, recommended way of handling unoconv listeners in a
> > automake file?
>
> The above is neither official nor (necessarily) recommended -- but (it
> is hoped) still useful ;-)
>
> From a reliability perspective, there are still a number of problems
> with the above example.
>
> For starters, the above snippet does not ensure that the SIGTERM
> actually caused the backgrounded listener to go away; you'd have to cook
> up some fancier mojo to ensure that using increasingly nasty and strong
> signals (SIGQUIT, then SIGKILL).
>
> Also, the 'unoconv --listener' invocation will fail if something
> (perhaps another 'unoconv --listener' process) is already listening on
> what unoconv(1) documents as the default port: 2002.
>
> Finally, unless you're using a new enough 'unoconv', the '&&' chaining
> won't actually short-circuit the invocations of the 'unoconv -f ...'
> invocations. This is due to an error propagation bug in unconv versions
> prior to 0.4 (released 2010-10-20).
>
> Not related to reliability, but the above example is also untidy in that
> it would leave the generated pdf, doc, jpg, and xsl documents laying
> around. It's conceivable that that could cause successive 'make'
> invocations to behave differently.
>
> > Thank You.
>
> You're welcome.
>
>
>
> HTH,
> -Al
--
Paul Elliott 1(512)837-1096
pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117
signature.asc
Description: This is a digitally signed message part.
