On Fri, Jun 17, 2011 at 07:35:19PM +0100, Graham Percival wrote:
> > >Again, on the shell, it would be something like this:
> > > make ...blah... || echo "build failed" && tail logfile
> > >but there might be a nicer way to do it.
> >
> > but then when blah fails, make will not stop, since the return
> > status from echo && tail is a success (assuming the log file
> > exists). How would you return failure and force make to stop?
make ...blah... || { echo "build failed"; tail logfile; false; }
> Interesting, I hadn't considered that. Hmm, is there such a thing
> as functions in bach? If so, it would be easy to return something
> after doing the echo.
>
> Of course, we can't guaranteed that bash will be present... does
> sh(1) allow functions?
Of course. Shell functions are demanded by POSIX ;-)
> Or can we write functions in make, or stepmake? Or do the same
> thing with macros somehow, if make has
> macros but not functions?
Please don't. Fiddling with (gnu) make macros (which aren't real
macros but just variables `invoked' in a special way) doesn't make
the makefiles more readable.
What should be possible (I can work on this in about one and a half
week, when I've two weeks of vacation) is something like this:
RUN_CHECK_LOG = foo() { logfile=$1; shift; ...; } && foo
...
a_target:
${RUN_CHECK_LOG} a_target.log ${MAKE} whatever
where the `...' in the definition of foo() in RUN_CHECK_LOG would
execute "$@" (i.e. the remaining arguments to foo() after the log
file name had been shifted away), and do the echo/tail/false combo
if it failed.
> The short answer is that I cannot believe that we've exhausted all
> options yet. I want Phil to look into those options; of course I
> welcome any suggestions from people on this list. But off the top
> of my head, I'd say that we can't possibly say that we're out of
> ideas until we've spent at least 5 hours googling and/or reading
> documentation about make and/or experimenting with make and
> stepmake.
Just wait a few days until I've some spare time available to help
you with this, will you?
I'll also have to read all this `silence the build' mails more
closely, because silencing the build *in geneeral* is a very bad
idea. If this all is about locating failures during the lilypond
(which *is* difficult IIRC), then the build system may be the
completely wrong place. (I can remember spending hours on tracking
down some errors coming out of ghostscript or metafont or fontforge
some years ago). If this is the case, the tools should be fixed,
not the build system.
Ciao,
Kili
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
