automake
[Top][All Lists]
Advanced

[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 09:30:43 -0400

Hi Ralf,

On Thu, Jun 23, 2011 at 1:52 AM, Ralf Wildenhues <address@hidden> wrote:
> Hi Mike,
>
> * Mike Frysinger wrote on Thu, Jun 23, 2011 at 02:08:50AM CEST:
>>       http://sources.redhat.com/automake/automake.html#Extending
>>       [quote]
>>       Note that Automake does not make any distinction between rules with
>>       commands and rules that only specify dependencies. So it is not 
>> possible
>>       to append new dependencies to an automake-defined target without
>>       redefining the entire rule.
>>       [/quote]
>>
>> i happened to notice though that automake only parses exact semantic matches.
>> it cannot handle going through variables.  so i tried out:
>> $(libbsdl_la_OBJECTS): bsdl_bison.h vhdl_bison.h
>
>> is this an undocumented feature ?  or a bug that'll get fixed at some point ?
>> we've been using this for a few years now without problems, but past behavior
>> does not guarantee future behavior ...
>
> I'd say there are two undocumented bits involved here: the name of the
> _OBJECTS variable, and the fact that automake only parses exact matches.
> Both are exploited in several user packages, esp. the latter one is,
> because in many cases there is no better way.
>
> I'd say that for any of those to change, it would require at least a
> major version bump, a big announcement, and most importantly, a
> documented replacement mechanism that works for all use cases.  And
> maybe even an upgrade path that warns users about their current code.
> I don't see that happening anytime soon.  The replacement mechanism
> would obviously have to be the first thing, to allow smooth migration.
>
> 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@
        DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @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?

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?

Regards,
Jie



reply via email to

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