[Top][All Lists]

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

Re: Generic mechanism for dependencies of CPP processed files

From: Thomas Schwinge
Subject: Re: Generic mechanism for dependencies of CPP processed files
Date: Sat, 14 Oct 2006 16:49:17 +0200
User-agent: Mutt/1.5.6+20040907i


On Sat, Oct 14, 2006 at 02:58:25PM +0200, Ralf Wildenhues wrote:
> * Thomas Schwinge wrote on Fri, Oct 13, 2006 at 05:08:48PM CEST:
> > As far as I know there is currently no generic mechanism in Automake to
> > universally support dependency tracking of files that are processed using
> > the gcc preprocessor.  Have people already made thoughts about such a
> > mechanism or how is the above scenario commonly handled?
> There have been various attempts at allowing to extend Automake more
> freely.  I can't remember any proposed patch that didn't need a lot
> of work (documentation, regression tests, and/or just portability
> fixes), and I also can't remember if any dealt with generic dependency
> tracking support.  But that doesn't mean they don't exist, just that
> neither you nor me have searched the mail archives yet.  ;-)

Heh, yes, thanks for the broad hint ;-).  But it's a bit difficult and
time-consuming to search for something when you don't know how it's
called.  I mean, I could invent a thousand names for the thing we're
discussing about.  But I'll give it a try.  :-)

> Since you seem to already have a suitable non-Automake mechanism in
> place, would you be willing to point us to it?  Does it clash with
> Automake in any way (note that you can override many rules and variables
> that Automake otherwise controls)?

There's nothing fancy about it: just a Makefile rule that uses the usual
GCC machinery (`-M*' options) to create a dependency file alongside the
preprocessed file and then have the Makefile include those files.  My
problem was how to get the files included in a way that Automake likes.
By now I figured out that `-include not-yet-existent-file' works, whereas
`include not-yet-existent-file' (as expected) doesn't.  With this
discovery, that problem should be solvable now (in case I don't decide to
stay with the following setup...).

In the mean time I also invented the following hackery which (compared to
the above scenery) makes (ab)use of Automake's facilities (with the
overhead of needlessly creating a .a archive):


noinst_LIBRARIES += \
nodist_lib_dep_tr_for_defs_a_SOURCES =
# Preprocess only.
lib_dep_tr_for_defs_a_CPPFLAGS = $(AM_CPPFLAGS) \

nodist_lib_dep_tr_for_defs_a_SOURCES += \
        vm/memory_object_user.user.defs.c \
nodist_libkernel_a_SOURCES += \
        vm/memory_object_user.user.h \
        vm/memory_object_user.user.c \
        vm/memory_object_default.user.h \


%.user.defs.c: %.user.defs
        rm -f $@
        cp $< $@
%.user.h %.user.c: lib_dep_tr_for_defs_a-%.user.defs.$(OBJEXT)
        $(MIGCOM) $(MIGCOMFLAGS) $(MIGCOMUFLAGS)                \
          -user $*.user.c -server /dev/null -header $*.user.h   \
          < $<


This will yield `foo.user.h' and `foo.user.c' files using `foo.user.defs'
by having Automake ``compile'' (read: preprocess only due to `-E') a fake
`foo.user.defs.c' (which has before been simply copied from the original
input file `foo.user.defs') to a fake
`lib_dep_tr_for_defs_a-foo.user.defs.o' (which is not really an object
file, but simply the preprocessed GCC output), which is then used as an
input file for MIGCOM to finally get the `foo.user.h' and `foo.user.c'
files created.  I hopy I got everything right here.  ;-)

The ugly thing are a) having to create an unneeded archive file and b)
the need to rename `%.defs' to `%.defs.c' in order to be able to
``abuse'' Automake's compile rule to create the fake `%.defs.o' and use
that as an input file again for MIGCOM.  But it works and does proper
dependency tracking, as far as I can tell so far.

Perhaps this example can be used to show what a generic solution would
have to provide.


Attachment: signature.asc
Description: Digital signature

reply via email to

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