Guy Harris <guy@xxxxxxxxxxxx> writes:
> On Sep 23, 2003, at 2:07 PM, Todd Sabin wrote:
>
>> Well, the errors caused by the missing x11-declarations.h were the
>> first errors.
>
> You didn't indicate that was the case, so I didn't know that was the
> case.
Sorry, I should have said.
>> Your comment about not wanting to see errors caused by earlier errors
>> seems curious to me. My understanding is that make -k only trys to
>> (re)build things for which all dependencies have succeeded. So, it
>> shouldn't generate build errors caused by earlier build errors.
>
> By "earlier build errors" I meant errors earlier in the *SAME* "make
> -k" run. If one step in the build is supposed to produce a file used
> by a later step in the build, the first step fails to build that file,
> but "make" continues rather than stopping, because it was run with
> "-k", and the later step would fail if the file that was supposed to
> be built by the first step is missing, the failure of the first step
> will most definitely cause a build error in the later step.
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. However, when it comes time to
link ethereal, make knows that its dependencies haven't all succeeded,
so it says:
make: Target `ethereal' not remade because of errors.
instead of trying to link it and generating linker errors. Of course,
this assumes that the dependencies are complete, so you might actually
see something like what you describe building ethereal, since there do
seem to be some missing dependencies. But that would be a problem
with the Makefile, not make -k.
>> You did "make ethereal" immediately after configure? Not "make" or
>> "make all"?
>
> Sorry - I hadn't noticed that it was specific to making individual
> targets.
>
> 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.
Todd
--
Todd Sabin <tsabin@xxxxxxxxxxxxx>