> Your 3 questions do not make any sense to me. I do not understand > the phrase "setting up make to anticipate errors". Make always tests > that each individual command completed with status 0, unless you pass > -k to tell it to carry on for as long as it can.
Awkward questions because without education I've made assumptions about how make does its job, and how it's used in complex projects. I had assumed that when it runs a test, it does it in a subshell, has set traps for what errors it expects to handle, and if it gets those, records what's useful but doesn't set an error condition so it can continue. Unexpected, untrapped errors would bubble all the way up to my invoking script and cause it to fail because I used "#!/bin/bash -e", as seemed to have happened. Just seemed to me if it's not "handled", then it's more meaningful. But all I know is how to run a make with a Makefile somebody who knew about the needs of the project made for me. OTOH, this isn't quite the forum for that sort of thing. Apologies. > I was thinking about things like ffmpeg and some of the AV libraries. > Things which for example use SSE3 variants if they are available. I saw that recently. Fortunately Firefox has a checkbox to disallow SSE3. That's about all I use on the web. (And of course, build.) > > > No, I didn't think so. OK, answer me this, since I'm NOT an > > > automake jockey. (Just got a book about it at Powell's by Vaughn, > > > et al., but whoa, way above my pay grade!) > > > ((Were you able to evaluate the book in-store - or online - prior to > purchase; the relatively-high level might've been apparent quickly. > Besides, it can be a good rule of thumb to try the package's own > (electronic) documentation first; and to beware thinking that there's > 'not enough time' to do so, while magically there is for a book. Not > assuming this/that applies to your partic case here. I was there with a friend on our way to the airport to catch her flight. No time for anything but the title. ;-) I'll keep it and go through it as I can. I'll glean something from it, I'm sure. > Offering perhaps a little expansion on that - NB the wording: Thanks for that. > I'd suggest that if using '-k' then take errors beyond the first one > with a pinch/grain of salt: ... > intensive. But you need to be aware of, and alert to, that - as you > seem to be alluding to in one of your questions - a later error in > make - k output might be due to a tangle-up from an earlier-reported > one from same make-k run: how difficult is it to differentiate between > such errors and other (separate/standalone) types of error in the same > output, often depends inter alia on how well you know the code. Yes, so after the first -k run, when I still thought I could find/fix it, I ran it again without so it would stop at the first error, clarifying just where it was. (And I never do -j parallel makes when I need to see what led up to the error.) -- Paul Rogers [email protected] http://www.xprt.net/~pgrogers/ Rogers' Second Law: "Everything you do communicates." (I do not personally endorse any additions after this line. TANSTAAFL :-) -- http://www.fastmail.com - A fast, anti-spam email service. -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
