[Top][All Lists]

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

side stepping automake limitations with custom dependencies

From: Mike Frysinger
Subject: side stepping automake limitations with custom dependencies
Date: Wed, 22 Jun 2011 20:08:50 -0400
User-agent: KMail/1.13.7 (Linux/2.6.39; KDE/4.6.3; x86_64; ; )

i'm working on a project (urjtag) that has yacc/lex files in it.  and other 
files in the directory depend on the generated output from yacc/lex.  so the 
automake file looks something like:
libbsdl_la_SOURCES =  \
        vhdl_bison.y \
        bsdl_bison.y \
        bsdl.c       \
libbsdl_flex_la_SOURCES = \
        vhdl_flex.l  \

since the bison(yacc) files depend on the output of the flex(lex) files, we 
want to express the dependency:
libbsdl_flex_la-vhdl_flex.o: vhdl_bison.h
libbsdl_flex_la-bsdl_flex.o: bsdl_bison.h

but with this, we hit an ugly limitation in automake itself.  FTFM:
        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.

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

ignoring the minor fact that a few extra objects depend on the headers than 
necessary, i get nice behavior: automake generates the compile rules for me, 
and i get to express the dependency to make so parallel builds dont fail.

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

Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

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