[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 |
Hello!
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):
#v+
[...]
noinst_LIBRARIES += \
lib_dep_tr_for_defs.a
nodist_lib_dep_tr_for_defs_a_SOURCES =
# Preprocess only.
lib_dep_tr_for_defs_a_CPPFLAGS = $(AM_CPPFLAGS) \
-E
nodist_lib_dep_tr_for_defs_a_SOURCES += \
vm/memory_object_user.user.defs.c \
vm/memory_object_default.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 \
vm/memory_object_default.user.c
[...]
%.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 \
< $<
[...]
#v-
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.
Regards,
Thomas
signature.asc
Description: Digital signature