[Todd Sabin <tsabin@xxxxxxxxxxxxx>]

Guy Harris <guy@xxxxxxxxxxxx> writes:

> On Sep 23, 2003, at 4:02 PM, Todd Sabin wrote:
>
>> Maybe I've misunderstood you, but you may want to recheck the -k
>> documentation and/or play with it some.  Your description above is
>> exactly what make -k avoids.  For example, in the "make ethereal"
>> scenario we're talking about, make -k notices that packet-x11.o failed
>> to build, but it keeps going trying to build the other components of
>> ethereal that don't depend on that.
>
> That was precisely what I did *NOT* want to have happen.  I wanted to
> see the output of the very first command that failed, without *any*
> other output after it, even output reporting that other stuff not
> depending on the output of the failed build was built.  I did *NOT*
> want make to go on trying to do *anything* after something failed, so
> I did *not* want it run with the "-k" option - i.e., "-k" avoids what
> I *did* want.

I realize you may not want to use the -k option.  I was merely trying
to point out that one of the things you apparently think or thought it
does is actually something it very carefully avoids doing.

>>> Fixing this would probably require some time spent reading the
>>> Automake documentation to see if there's a "right" way to handle this
>>> or if we just have to add dependency rules.
>>
>> I try to maintain a healthy distance from automake/autoconf, so I have
>> no idea how they're supposed to interact with dependencies, but this
>> "feels" like it's "just" a matter of listing dependencies right in
>> whatever input ultimately results in Makefile, for what that's worth.
>
> That's probably the case, but there might be a way to have automake do
> a lot of that work for you, for example.  (I.e., do you just put
> explicit dependencies in, or do you set some automake variable and
> have automake generate the dependency rules for you?)

I'm clueless when it comes to automake.


Todd

-- 
Todd Sabin                                          <tsabin@xxxxxxxxxxxxx>