[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).