[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: subdir-objects fails with non-literal _SOURCES

From: Jim Meyering
Subject: Re: subdir-objects fails with non-literal _SOURCES
Date: Sat, 21 Apr 2007 21:10:22 +0200

Hi Ralf!

Ralf Wildenhues <address@hidden> wrote:
> * Jim Meyering wrote on Tue, Apr 17, 2007 at 09:16:59PM CEST:
>> Ralf Wildenhues <address@hidden> wrote:
>> ...
>> > The strongest argument against invoking `make' at the end of configure
>> > is one of debugging: if your makefile contains a syntax error -- and for
>> > newbies it frequently will -- then configure won't finish successfully.
>> If you're tempted, maybe a two-pronged approach.  First use the naive
>> sed-based approach, but if there are any '$' in the result, try using
>> "make".
> Not such a bad idea, but...
>> If make-based process fails for any reason, simply continue
>> with the results (guaranteed to fail upon build attempt) of the
>> sed-based approach.
> ... what if make decides to rerun `config.status --recheck &&
> config.status', say, because the user has his CONFIG_STATUS_DEPENDENCIES
> wrong?  I don't see an easy, non-error-prone way to guard against the
> ensuing endless loop.  Of course the same failure would happen at the
> time the user typed `make' later, but:
> - maybe he knows what he's doing and knows not to type `make' right now,
> - maybe he knows to run gmake later (which won't rerun config.status)
>   but has not issued `configure MAKE=gmake' (in which case we don't know
>   to use gmake over ${MAKE-make}).

No problem :-)  Just disable the potentially-offending rule in
the temporary makefile that is probably already required -- see below.
> I've encountered both failure scenarios before, with me being the user,
> or the developer in the process of fixing the build system.  These
> things are tricky enough when you see what's going on, but supposedly
> the new depout.m4 would hide $MAKE's output, no?  Thus making debugging
> neigh impossible.
>> Then, it should work no worse than the existing code, and
>> you can hide any make diagnostics so as not to confuse newbies.
>> The only cost is the added complexity.
> Complexity is another counter argument, yes.  There is already a lot
> complexity in Automake, in that it is quite difficult to expose all
> cases well.
> FWIW, I overlooked your (nice!) idea to avoid a temp makefile.

Thanks.  Unfortunately, I doubt usage like this
is portable enough to use there:

  echo 'target:; rule...' | make -f Makefile -f - target"

So we'd need a temporary, makefile, as well as code to
clean up afterwards (and upon interruption).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]