[Top][All Lists]

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

Re: side stepping automake limitations with custom dependencies

From: Jie Zhang
Subject: Re: side stepping automake limitations with custom dependencies
Date: Thu, 23 Jun 2011 16:25:44 -0400

Hi Ralf,

On Thu, Jun 23, 2011 at 4:02 PM, Ralf Wildenhues <address@hidden> wrote:
> Hi Jie,
> * Jie Zhang wrote on Thu, Jun 23, 2011 at 03:30:43PM CEST:
>> On Thu, Jun 23, 2011 at 1:52 AM, Ralf Wildenhues wrote:
>> > The only thing that keeps me from setting current behavior in stone is
>> > that it is sooo unintuitive and ugly.
>> >
>> There is another ugly way to achieve the same purpose, i.e. redefine
>> the entire, like this:
>> vhdl_flex.lo: vhdl_flex.c vhdl_bison.h
>> if am__fastdepCC
>>         $(AM_V_CC)$(LTCOMPILE) -Wno-error -MT $@ -MD -MP -MF
>> $(DEPDIR)/$*.Tpo -c -o $@ `test -f '$<' || echo '$(srcdir)/'`$<
>>         $(AM_V_at)$(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
>> else
>>         $(AM_V_CC) @AM_BACKSLASH@
>> if AMDEP
>>         source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
>> endif
>>         $(LTCOMPILE) -Wno-error -c -o $@ `test -f '$<' || echo 
>> '$(srcdir)/'`$<
>> endif
>> This way also references several undocumented internal variables of
>> Automake. Which way is preferred? or less ugly?
> Well, this is waay more verbose, prone to bitrot as the automake-emitted
> rules are improved over time (which is more likely than anything else),
> and in this special case also unportable, as $< in non-inference rules
> requires GNU make.
Yeah, I agree. I saw that BFD in Binutils uses this method and thought
it might be the "standard" way to deal with this situation. It seems
we would better to use the undocumented feature, since Automake
maintainers are aware of this. :-)

>> The root cause of this issue is that Automake does not distinguish
>> rules with commands and rules that only specify dependencies. I'm
>> curious that why Automake does not distinguish them. Is it too
>> difficult to implement or it is also a feature or just because no one
>> does it?
> With Posix make Makefiles, it would be doable with some more work, but
> automake doesn't.  With GNU make extensions used in the, it
> is almost impossible without implementing a large set of GNU make
> extension parsing in automake as well.
With my limited Makefile knowledge, I thought it was enough to look
one line ahead to see if the next line started with a $.RECIPEPREFIX.
If yes, this rule has a recipe, if no, this rule is only for


reply via email to

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